Parent & Derived Roles
The concept of parent and derived roles was introduced by SAP to simplify role administration tasks. Its specially helpful while mapping security for large enterprises spread across multiple geographies or divisions. A child role derived from a parent role will have all attributes (transactions/ authorization object values) same as it parent except the values of the Organizational Level fields (plant, company code, sales organization). Thus maintenance is simplified as only the org levels need be maintained at the derived role level. This also ensures that there is no opportunity to make mistakes during authorization maintenance for the multitude of derived roles and also reduces testing effort for roles.
Creating the parent role follows the same process as creating any other single role. In the example below we create a global role “Z_CREATE_SO_GLOBAL” which allows the creation of Sales Orders (transaction VA01) for all company code, sales orgs.
With the parent already defined we create a child role “Z_CREATE_SO_US” which allows SO creation for the US companies. We maintain the parent role name as shown below.
The menu for a derived role can not be individually maintained as all entries are inherited from the parent.
Now we maintain the org levels values relevant for the child role. In the example below, we have used a dummy value of @ but in a production system the correct value for org levels should be used. The other other need not be maintained at this stage. Now we save the authorization entry for the derived role.
To populate the rest of the authorization values for the child role, we go into the authorization maintenance screen for the parent and click the button “push from gl”. This option pushes the non org level values from the parent to the child role and generates the profiles for both.
The most critical success factor for a parent-derived role concept is how well, the different business processes mapped by SAP roles are mirrored across the different divisions in an enterprise. In other words, a parent-derived role concept will not be very beneficial in case an enterprise follows different business process in its different subsidiaries.
Hi,
thanks for your articles. What I’m interested in is the value-roles approach. What about your experience with creating different roles for Transaktions (T_CODE), “common objects” and org-levels and assigning a set of these roles to a user knowing that the object will be provided by the additive auth. buffer?
Maybe you can come up with an article about that concept.
Thanks,
Gerhard
Hi Gerhard,
Thanks for the idea. I just started on a post about Value Roles. Should be ready in a few days. However, I will confess that I am somewhat skeptical about the efficacy of value role based security design. So you might find the article just a bit biased:-)
Regards,
Aninda
topics & desp are good
hello aninda
How you doing. will you please answer one of my questions
if u assign a role to user. He is executing the role with out problem but my question is user is executing tcode but he got perticular screen with missing tabs , how could we solve this problem
awating for your answer
Regards
krish
thisiskrish@hotmail.com
Hi Krish,
If you are getting access to the tcode but some options are missing, there might be subsequent security checks which are failing for the user. Use the security trace (transaction ST01) to investigate the missing access. There is a post on this site which mentions the details of how to use the security trace.
Regards,
Aninda
Hi Aninda,
I need information/step by step procedure about CUA set up..
Kindly post me
hi Aninda,
thanks for the information..it is v productive.
Regards,
Rakshith
1.client should be created by using scc4(tode).
2.logical systems should be defined by using sale/bd54.
sid.
3.Rfc connections should be defined by using sm59(tcode).
two users are created parent&child systems.
user type is (communication user)
also roles should be assigned to users.
sap_bc_usr_cua_client.
sap_bc_usr_cua_rfc
sap_bc_usr_cua_central_setup.
sap_bc_usr_cua_central_client.
Hi Aninda,
thanks for your first class explanation of authorization issues. Just want to know the following topic:
I want to add a new auth. object to a parent role which has about 20 child roles due to company codes and sales orgs.
I have changed the parent role with the new object and generated properly with the red-white beach ball and then transported to QA. But the in the target(QA) system, all the child roles had red lamps in auth. flap which were previously green ! What happened ? Will bepleased for your advice.
Thanks in adv.
Kumar from Germany.
Hi Kumar,
The entire concept of the lights in the authorization tab turning green/yellow/red is controlled by the timestamp of the role and profile. Did you generate the child roles (push authorization values) after inserting the object to the parent? Ideally both parents and child roles should have been generated and roles and profiles of all should have been transported to QA.
Regards,
Aninda
Hi Aninda,
its aweasme site. i am fresher and working in MNC in SAP Security. i am struggling in. can you guide me how i should go and learn ?
The site is expressly for freshers like you. Go through the articles in the order they appear in the drop down menu or the left hand side menus. The articles under “Getting started with Security” is a good place to start.
wen wil go for excute and simulate in grc rar
Hi Aninda,
the back ground job “PFCG..TIME_DEPENDENCY” is turning the green-buttoned authorizations into “Yellow”, how to stop it !
I have changed the variant “Without clean-up”, but still it’s done that non-sense !
‘will be pleased for your advice.
Thanks
Kumar Mitra
Germany
===========
Hi
I want to know the concept of single ,composite and derived roles.what is the purpose of using this
Thanks…….. ANINDA……good article…..
Thanks….
Good article for all who are working on sap security.
Hi ,
I would like to know if there is a way to maintain different org levels in a derived roll with different activity? for example
1. activity = 03 , company code = 1000
2. activity = 02 . company code = 2000
thanks
Itai
You are out of luck. I would suggest that you re-think your design!
Hello,
Can you tell me the correct way after we have made the change
to the Org Level Values of any existing derived role.
1) After making Org Level Changes, we GENERATE Profile for that derive role there. Again go to master and click on Generate Derived roles and then move them both in a TR?
2) After Org Level Change, we only SAVE the Derived role and not Generate the profile.Go to Master Role and click Generate Derive roles and transport both in a TR?
Both of the two processes will work. The important thing to remember is to ensure that you click the generate derived roles button from the master. Also if you create a transport for a derived, SAP automatically includes the master in your transport.
Hi Aninda. Thanks a lot. I have 1 related question for which I need little help. It is urgent.
I am making changes to the Org Level (adding/removing Plant codes)….So…this is what I do … (Please correct me)
1) Go to the Derived Role,
2) Auth Tab Option – CHANGE AUTH or EXPERT MODE (Read and merge with new) …
Here i selected ‘Expert Mode’ (Read old data and merge with new) …
In Auth screen, I saw 1 YELLOW Button in S_TABU_DIS for a table. So, I made this as INACTIVE (as it was inactive in MASTER ROLE). This made the lights go Green.
3) Then I made the Org level changes by adding/removing Plant codes as required.
4) Click on ‘Generate’ for generating profile of this Derived Role.
5) Go to Master Role, go to CHANGE mode
(Que-DO I need to keep only DISPLAY MODE & click on ‘Generate’ profile in auth screen).
In Auth Tab, Do I need to Select CHANGE AUTH or EXPERT MODE ?
ONce I go to the Auth Screen, I will Click GENERATE PROFILE.
(Que- Do I need to click on GENERATE DERIVED ROLES Roles.)
6) Come out of Maste Role.
7) Create a TR with Derived and Master both.
Hello,
i see that the changes once made in child roles, eg: cost center are lost once i update some information in Master role and generate it, is there a way in which i can handle such situation.
You are not suppossed to update anything other than org level values in child roles.
Hi,
I have a query related to organisational levels.
if we change the value of organisational levels in derived roles will it effect the parent role or there will be some error?
Thanks
Abhishek
Nope. Org Level values are suppossed to be updated in the child roles.
Hi Aninda,
I am working on master and derived role, I have updated the activities in Master role and pushed the changes to derived roles. now I need to carry the changes to Production system. DO I need to transport all derived roles or Just master roles to Production.
You would need to transport both the master and derived roles.
Hello Aninda,
Thanks a lot for this wonderful site.I nned your help on one issue.
There is a requirment from business to add and remove a tcode only from 1 derived role out of 5 derived roles present for a parent role.
Is it possible somehow to achieve this.
This cannot be done. All derived roles will have the same tcodes.
Hello Mayank,
It is possible to add a tcode in derived role separately.
Process:
–> add S_TCODE auth. object in dervided role
–> Under this object add the tcodes which you want to add (in TCD field)
–> after that add all associated authorization objects manually
–> maintain the field values as per your requirement
–> Save the role and generate the profile
Regards
GS
This is not a feasible solution. The newly added S_TCODE values will be wiped out once the values are pushed from the master role. Also it defects the function of derived roles where the derived roles and master roles only differ in the org level values maintained in them. Thanks
Hi,
Good day..I have a query regarding role transports involving Parent and derived roles.
1. I know that when we transport Derived (Child) roles, the Parent role gets included in the Transport. This I understand is the SAP standard process.
Would it be possible to provide more information related to the SAP standard process regarding this.. A link to refer would definitely help..
2. Due to the inclusion of the master(parent roles) we end up getting a lot of Transport collisions. We have approximately 100-150 Child roles per master role. As a result, though, while there might be no actual changes on the Master role, and maybe only an Org level update on the child roles for different locations, we still have to look at a lot of transport collisions, due to changes for different locations.
My questions are :
1. If we remove the Parent/Master role from the transport, would it cause any issues. Would it also affect the Inheritance in any way or cause any authorization issues later on..
2. Also, Will transporting only the Master role and then deriving the child roles work in the above scenario..
Please advise..
Regards,
Prakash
Hi Prakash,
Unfortunately I don’t have a link to “official” documentation talking about the transport process.
If you are updating org levels, you shouldn’t be have to touch the master roles at all. Just update the affected child roles with new values and generate these roles individually. Even if the masters are automatically included in the transports, there won’t be collisions as the same master roles with the same time stamps would be included in all the transports containing the master. I don’t believe its a good idea to remove the masters manually from the transports.
Thanks,
Aninda
Hi Aninda
please provide all authorization objects for org level fields
Hi Aninda,
I am impressed with your website and the intelligent articles you post, and I wondered if you could help me.
I am implementing the master \ derived concept for HCM at present and I have an issue with P_ORGINCON authorisation object. It would be very useful to create one master role and then control child roles by PERSA and PROFL so that different structural auths can be assigned for certain ‘areas’ of the organisational structure.
eg. with PERSA restricting by location and then PROFL by business stream (cut across org structure).
At present I have the option of:
a) entering all values in PROFL in master role and relying on table T77UA being well maintained to only allow a single, appropriate profile to be brought through for each user.
b) leaving PROFL blank in the master and maintaining the values individually in each child role after every update of the master role.
Can you advise if it is possible or advisable to set up PROFL as an organisational level data value via PFCG_ORGFIELD_CREATE so that it can be maintained alongside PERSA?
What issues do you foresee in doing this?
Many thanks in advance
Hi Andy,
It all boils down to your requirements. I have used both PROFL and PERSA as both org levels and normal authorization fields in different systems. The one problem that sometimes comes up with PROFL as an org level is if the same role has different structural restrictions for different infotypes.
Thanks,
Aninda
If PROFL is set as organizational value, you state, that you had issues, if more than one structural profile is used in the same role. But is the problem, not only, that you cannot control this from the organizational tab?
In the question, is it statet, that it would be possible to leave the PROFL with *, and then relate on the entries in T77UA. But is it not so, that the P_ORGINCON is using the profile entered in PROFL and not the profile in T77UA?
Thx in advance
Birgitte
You can certainly have PROFL as * in the role and control the actual assignment via the OOSB entries. Whether to promote it to an Org Level is decision based on your design of the roles. Thanks.