Enabler type role design

[Former Member]

Hi Experts!!!

We are putting up a project plan for security role redesign. Today we have the master derived role concept. We have restrictions on both org levels and non org levels. We have derived roles out of sync and a lot of maintenance overhead. We have a couple of other roles designs with the companies we acquired and integrated. The management really wanted to standardize business processes and we want to propose role redesign with the same. We were planning on going with the enabler type role design as today we have a lot of org values and the number of roles to modify when a new org is created is very high. This made us think of the enabler type roles. Can you please help us go the right way with this approach.Wanted to get an idea of the do's and dont's with this approach . I have read a few threads on this and got a mixed responses. It would be really helpful if we can have specific drawbacks and advantages of enabler type role design. We are going with self implementation.

Thanks in advance for all the responses.

[Former Member]

This is the worste possible approach imaginable.

Please read the FAQ sticky thread for some of the related flamewars. Other search terms are "hit by a bus" and "bolt on".

You should not be scared of the number of roles if you build them well. You should concentrate on miminizing the number of roles the user needs to have to perform their various tasks.

If you are tempted into using local client specific composite roles, then there is always an optimization opportunity to build bigger single roles.

The "acid tests" for role design are upgrades and imagine that the user can request a role via a portal application - they should be able to find it!

"Enabler roles" as a large scale concept are a huge problem after go live. At most you could tolerate a few "delta roles" but they should ideally not havee any org. levels in them.

Cheers,

Julius

[Former Member]

I have read a few threads on this and got a mixed responses. It would be really helpful if we can have specific drawbacks and advantages of enabler type role design. We are going with self implementation.

This question generally sparks some debate and has been discussed in detail on more than a few occasions. I would encourage you to read through these older threads to pull out some of the information you are looking for.

I recall that these related threads had a fair amount of well thought out responses

[|]

[|]

Each has some in depth discussion on the pros, cons, and other items to watch out for. If you are looking for a complete how-to guide, I would be a bit skeptical as to do this correctly requires a proven and structured approach to ensure you get things right.

[Former Member]

Hello TD,

Not a how to guide but the things considered for task based roles, enabler type roles and things to take into consideration to implement it right.

Thanks,

Raghav

[Former Member]

The probem is sustainability.

Latest when you upgrade such "building block" task roles then the **** will hit the fan..

Of course, by then the consultants are all gone....

Cheers,

Julius

[Former Member]

Hello Julius,

We are planning on a self implementation...the threads are scaring me....we have a a lot of org values and non-org value restrictions...for example a couple thousand plants and a couple thousand shipping points...have a standard derived role concept is resulting in a maintain nightmare and want to have task based roles and enabler type roles to be scalable and significantly reduce the invalid SOD's etc.

thanks,

Raghav

[Former Member]

The question you should be asking yourself is how many job functions you have and job descriptions (and try to build roles at that level).

How many users do you have? (you should not have more roles than users, because then something is wrong i the design / naming conventions).

Cheers,

Julius

[Former Member]

today we have 20k users and 20k roles in the system...which include all single/master/derived roles...

[Former Member]

Also, since we are global...the job positions are not consistent across....task based roles will give the flexibility to assign task specific roles and enabler type roles will help control...knowing this concept in depth would be helpful to make a perfect design and hence all the queries.

Thanks Raghav

[Former Member]

hi raghav, do not use enabler roles. They are the worst possible approach. the master and derived that you are using has not been properly segregated. 1 tip is , segregate Module wise, i.e MM,SD,PP,QM,etc... and not like Supplu Chain, Procurement, etc..

Example :In MM, segregate through each Conflicting activity ATLEAST. i.e PO creation and approval should be in separate roles.

Further, PO roles should be segregated through Doument type. Similarily for all other modules.

This apporoach will easily accompany Other Companies that you are mentioning about. I had exactly a similar scenario, and Master-Derived is the Best solution for this

[Former Member]

In general an AP clerk will do 90% of the same activities regardless of location, the same for a warehouse manager. Take a risk based approach to grouping functionality under those and only then look at a solution for providing access.

Security design is always best done top-down with the principle that there are an absolute minimum of jobs to support the controlled execution of business processes.

Using enabler roles and tasks will not necessarily reduce your number of roles, but it will increase complexity.

Lets do some numbers:

For every task you will need a corresponding set of enabler roles. If you have 10 plants then that is 11 roles - one for transactions, ten for restrictions. If you did the same using derived roles then you would be in the same situation.

If you have 300 tasks at plant level then you will have 300 + 3000 = 3300

An argument often proposed is that you will have 1 set of enablers covering a large number of tasks. Lets do it for the plant based area I mentioned previously

300 + 10 = 310

That looks attractive! but consider what you are actually doing. By creating these "buckets" of restrictions you are putting significantly more access into the enabling role than is required to execute the transactions in your transactional tasks. If the authorisation concept worked differently then this wouldn't be a problem, however at the most basic level you need to consider all those transactions which let you navigate to other functionality through the menu (transaction, not role). This access will not be restricted as you have given all those extra auth objects in the enabler "bucket".

You mentioned SoD's. Question: at which point does an SoD really matter? Answer: when it is assigned to a user. Task build is a lazy way to demonstrate that roles are SoD free. It is at the user level that the risk can occur (that is not to say that we don't build to be SoD free as possible). You may have SoD free tasks but it unravels when they are grouped together to make a users job.

Lets consider SoD checking a bit more, most of the publicly available tools check at tcode and auth object level. How do you propose checking your tasks for SoD's? At transaction level it is meaningless. To do the object combination you will need to simulate the correct pairing every time. An analysis on 300 tasks will not be a trivial matter (unless you group them into composites - another level of complexity forced by choice of design).

By all means take the enabler approach but go it with your eyes open and I would seriously recommend putting together a balanced scorecard which objectively assesses your different approaches against the requirements. If it scores badly then look at why that is. It is highly likely that taking the enabler approach will cause significant access creep and require a rework in the medium term. If you are recommending this then make sure all your bases are covered and that you have contingency to address all of the risks that have been highlighted in this thread and in some of the others that you have viewed.

[Former Member]

Thank you Alex for your input...can you please help me with the disadvantages and the scenarios where i can go out of control with the role maintainability...I would like to capture the disadvantages with this approach vs the standard approach.

Thanks,

Raghav

[Former Member]

I've created and hated this build option - having moved on after implementing as agreed and then moved into companies using they are a nightmare...

Combining overall object requirements to support different singles is just plain dumb.

at which point does an SoD really matter? Answer: when it is assigned to a user

For GRC's role level/user level reporting I totally agree - the real risk to the business is when the user gains combined access and I'm fairly sure there are SAP standard role out there riddled with SoD's

Cheers

David

Edited by: David Berry on Oct 6, 2011 8:44 PM

[Former Member]

Hi

...can you please help me with the disadvantages and the scenarios where i can go out of control with the role maintainability...I would like to capture the disadvantages with this approach vs the standard approach.

This is down to you to provide and steer (IMHO) as it shows you know what you're talking about.

Cheers

David

Edited by: David Berry on Oct 6, 2011 8:47 PM

[Former Member]

Alone the fact that there are 4000+ auth objects and complex fields and values basically rules out enabler concept maintenance.

If all RFC enabled FMs have to make some additional auth check then it might easily explode to 10k+ objects (but most likely they will only have one field...).

Proposals from menus and monitoring manual / changed auths in the build is the only sustainable way IMO.

What counts most is the (high as possible) level you build single roles and how many are assigned to users (few as possible, but big).

If you demote some org level fields and your roles are SoD okay for your requirements, then you have done a good job...

It is IMO not possible to leave a good job behind you if you build enabler or bolt-on concepts at a large scale.

Cheers,

Julius

[Former Member]

Thanks Julius, you saved me a few key strokes.

Raghav - a couple more for you (there are a few in my earlier posts and in the link from TDCumm16

High Complexity: Could an average security admin understand your design without significant handover?

Breaking with standard method of building security: PFCG and SU24 exist for a reason, break one of them at your peril (upgrades, security patches etc)

Interestingly I've heard that a couple of the Big4 are pushing this design principle hard in some of their territories. It will come back to bite them. Innovation is great when it delivers benefits but not when that benefit case is mis-sold.

[Former Member]

I completely agree with Julius!! Enabler role concept is one of the worst adapted design methodology...however sadly it is now widespread!!

Most of the designers don't realize that there is something called upgrade in SAP and people would go NUTS if you have this kind of design.

I am currently working on an Upgrade Project where the enabler concept has been adapted. After the upgrade all the enabler roles has been updated with 300 new auth objects which have atleast one field in the Org Level; on and above previously existing 200 auth objects.

The reason is you never know which single roles will have which auth object with a corresponding field in Org Level that's why you will have to manually add all auth objects in the enabler role which has org level fields.

Also I understand that with Enabler role concept you need to assign atleast two roles to an user. But with a derived role concept it is only one. Don't know who coined this term "Enabler Role"???!!!??

[Former Member]

Upgrades are always the "acid test" for role designs.

It effectively rules out such "bolt on" concepts (I believe Raghu Boddu coined the phrase) and "enabler roles" (I first observed Alex Ayers using it many years ago, but not favourably... ;-).

We wrote some blogs about it as well (search for "How to get hit by the ABAP authorizations bus and survive")

Cheers and thanks for your insighful contributions to the SDN discussions

Julius

[Former Member]

Thanks Julius!! Not sure if I contributed anything here...but with your feedback it definitely contributed to my confidence to fight against the Enabler Role concept