Transaction & Value Roles
The idea for this post was suggested to me by one of the visitors of this blog, who had put in a comment around the use of value roles in security design. I though that the question was general enough to merit its own post instead of a reply to the comment. Let me first begin with a confession, though I have worked in a few set ups using this concept, I have never understood their effectiveness in security design. For me, value role create more problems than they solve. I agree that my views are colored by the projects that I have worked on and elsewhere, their use might make a whole lot of design sense. If any of the visitors have any experience in innovative use of value roles which really simplified security design, please feel free to comment. A healthy discussion on the subject will help everyone of the readers including myself!
The transaction and value/controller role concept revolves around creation of separate roles for transactions ( with S_TCODE) and authorization objects with org level values. The latter are the value roles as the individual values for the org levels are maintained therein. Elsewhere they are also known as controller roles or enablers, as they control the final access to a transaction. The transactional role in addition to S_TCODE also contain the authorization objects which do not have org level values. Since the value roles do not have transaction in their menu, the authorization objects are manually added to them. During assignment, both transaction and value roles need to be assigned to a user (sometimes via a composite role). There is no hard rule around the number of transaction or value roles. In a typical scenario, a transaction roles might be created to map the different jobs defined in the enterprise. A possible starting point of such a design will be provided by the user-transaction matrix. After the transaction roles are set up, a few broad value roles are created with authorization objects needed for a functional area (SD, MM, HR, FICO etc). The number of value roles generally will be much lesser than the number of transaction roles and will have all or most of the authorization objects belonging to the functional area. We can also have separate value roles for display and update and also different ones for the different ones for the various divisions in the enterprise.
I believe the initial logic behind adoption of the value/controller roles was reduction in maintenance effort. For example, instead of maintaining tcodes and authorization objects in all roles, we just add the tcodes to the single transaction role and the authorization objects to the value roles. In fact, since SU24 entries are not involved (authorization objects are manually added to the value roles), value roles will be only be need to be updated for a new authorization object (i.e. an object not used in the transactions being already used). Some people might also consider it to be a cleaner design, to keep the transactions and authorization objects separate.
After knowing the background of value roles, lets explore the problems created by their use. For me the biggest casualty of the value roles, is the loss of all information contained in the SU24 entry for the transaction as transactions and the objects needed for its execution are present in different roles. Without strong documentation practices, we can often end up with a situation where no one has any idea why a particular authorization object was added to a value role. A direct result of the above problem, is the fact that most value roles have more authorizations than are needed for execution of the transaction present with a user through a transaction role. A further problem arises because in many cases SAP allows us to jump to different transaction screens by following navigation options in the menu for a tcode i.e. moving from a display to the corresponding update transaction. Even though SAP would normally check for update activity in such a case, a S_TCODE check might not be enforced. Hence, user would get access to an update transaction through the value role even though transaction role only allows the display version. There might be many other such cases, where access present in the value roles might open up extra access with the tcodes present in the transaction roles. Finally the security testing effort is also increased a great deal as without the use of SU24 to guide us, the only way to determine the complete access needed for a tcode is run a trace for each new transaction and check each of the value roles to ensure that they contain required access.
I have already mentioned my skepticism for the value role concept for security design. In fact, I am even unwilling to accept the argument about less maintenance effort for value roles as the same can be realized with a parent-child role based design. However, there is overwhelming majority of security installations which continue to use value roles. If any senior security experts are currently reading this post, I would sincerely request their comments on the same as its extremely probable that I am missing something about the potential benefits for value roles.
Value Roles in my view is an outdated concept. The way I am aware of it, is little different – Transaction maintained in one Role with all objects maintained except for those involving orgs. Org related objects are maintained in separate Value Roles. This limits the control you can have from Security POV. As once you assign a value role it combines with all the transactional roles and gives access at that level through out. So if you want to resrict some roles at lower level for that org, that becomes difficult. Derived roles is a much better solution, period.
Hi Sean,
Thanks for your very informative comment. I agree with the gist of your thinking. The article doesn’t specifically mention about putting only the authorization objects with the org levels into the value or enabler roles. I propose to update the post to specifically include this.
Also as you mention, derived roles are a much newer and as I too believe, to be better concept. However, there are a quite a huge number of functional builds which still use value roles. Security in general seems on the paradigm – “if its not broke, don’t fix it” so getting business buy in to update a system with value roles to derived roles will prove to be difficult for most of the security consultants out there. And surprisingly, even new builds still continue to use the value role concept.
With the proper amount of documentation and foresight, value roles – enablers – controllers can still be used effectively and result in much smaller roles to maintain. For example, I have seen hybrid systems where the value roles themselves are derived from a master so that the non org level fields are shared across a multitude of roles.
Regards,
Aninda
Hi Aninda,
It will be great, if you could add some stuff in compliance and firefighter access restrictions. and litter more highlights on JAVA security.
appreciate your response.
with rgds
Mohammed
HI Aninda,
will you provide GRC Information,
Regards
Hemanth
Initially I “quacked” at this design concept untill I realised that it saved a lot of maintenace effort when for example, lots of authorization failures were calling P_ORGINCON values. In this case I found out that going to the same role to fix P_ORGINCON related failures saved a lot of time. If you designate only one role to maintain infotypes then you don’t have to have several scores of roles with pretty much the same maintained authorizations during testing.
I still do not recommend this approach as it creates a nightmare for other Security Analyst who work on the roles later. I had a rough time finding out where to maintain failed authorizations when almost every HR role had P_ORGIN/P_ORGINCON deactivated. I agree it saves time but that is the only bennefit to this design approach.
Hi,
I have a little bit confusion about authorization objects. I create a MM role, but there are objects requires which is FI (asset posting). Our consultant says, it is not possible to add those because it will cross to another module. But my client need it to continue to their transaction. I check in SU53 and its check with no proposal. Do i need to add it to the role, whereas my client is function as limited?
There would always be auth objects of different classes in a single role. There is just no way out of it. Many MM tcodes which deal with materials posting would need access to the FI objects which control posting.
Hi Aninda,
Have read this article regarding transaction/value role concept. I’m in a major implementation where in our scenario, we have around 200+ plants and it seems that we would have a huge number of roles if we follow the Master/Derived concept. For example- PM module have sorted out 7 master roles, So if we create roles for every plant then we would have around 7*200=1400 roles for PM only.
The same situation is common for most of the modules.
So I think this transaction/value based role would suffice our problem. But its complex as you said.
What do you recommend- how should we go about building the security roles architecture ?
Thanks & Regards,
Raichand
Hi Raichand,
I would still go with derived roles because long after your implementation is over, the derived roles will be far more manageable than the transaction and values roles/enabler roles. A lot of the tasks involved in creating derived roles can be automated by the use of LSMW or SECATT scripts. You can even work with your ABAP team to help creating code for updating of org level values.
Using enabler roles will lessen your development time, if you decide to have one or two enablers per module (like PM) instead of the 7 roles you already have. However, this would mean that users get far more authorization objects than they need to execute the tcodes that they have access to via the transactional roles. If down the road you need to limit access, you would find if difficult to remove appropriate objects from the enablers.
Thanks,
Aninda
Hi Aninda,
First of all thanks for the blog and covering all good topics. It’s really helpful. Also sorry for replying so late to this blog but I came across it today.
About value role concept, I did came across the customer who have used it moderately. Security design was to use master and derive role and the thumb of rule is to have t-code to be added/appeared in one role. e.g. If I search role for T_CODE PA20, I get only one role in the system. But in the derive role P_ORIGIN would be updated with value ”. The new value role would be created adding P_ORIGIN authorization object manually. Now this role would be created for each team member who have different requirement of viewing data. So e.g. HR Administrator will get Derive role PA20 + Value role having P_ORIGIN Infotype 0001,0002,0008. Payroll Administrator will get Derive role PA20 + Value role having P_ORIGIN Infotype 0001,0002,0015.
The other example is ME21N – Create Purchase order where all the auth objects related to ME21N will be added and updated in Derive roles but value role will be created having manually added Auth object M_BEST_EKG (Purchasing Group in Purchase Order) and based on user’s Org structure, the value role to be assigned to give access to required Purchasing Group.
Hope I have understood the concept of Value roles and clear on the example given above.
Thanks again.
Hi Chetan,
Traditionally, value roles did not have any transactions added but only the authorization objects with values that changed across different versions of the value roles. I think you have got the concept of value roles but you are probably using a hybrid concept where both derived and value roles are being used.
Warm Regards,
Aninda