Question:
We have setup all the roles and tested successfully for one company code. Now I am finding an effient way to deploy the same roles to other 19 company codes.
Setup the new roles is not a problem -- CATT works great. Our concern is heavy maintenance workload. Everytime we change a role (add a T_code, change a auth object value, etc..), we need change it for other 19 roles. Maybe you agree we seldom change the organization level for a role, instead, only non-org level auth object need be adjusted for maintenance.
How about we split the authorization profile into 2 parts: One contains all organization level, and it is specified for each company. Another is all non-org level auth objects, and it is common profile for all companies. Everytime we just need change the common profile if no organization objects changed.
Does anybody have good/bad expience about it? Or you have a better suggestion?
TIA,
James
Answer:
What version are you on? If your in >= 4.6 and all of the roles are going to have the exact same transaction look into derived roles. This will only work if the business process is exactly the same and unique changes are not needed for the different org specific roles.
Answer:
Hello James
I think there is a possibility to define generic rols that contains all the transaction. You can include specific authorisation.
From that role you can create company roles that are adjusting itself to the generic one. That specific role you enter the company authorization like company code, sales organization, purchase organization etc..
So when you are modifying the generic role that is reflecting to all role that are using this one as template.
You should find information into Authorization made easy document.
I hope that will help. I knwo that doesn't explain how to do it, but I simply see it ones and that is 9 months ago.
Answer:
Yes there is a simpel way which has been done by us.
The best way to do this:
1st create normal roles in these set the OrgLevel to Dummy (" ")
2nd create OrgLevel roles (based upon Composites or any other combination of roles that are assigned t users) and fill these with all the Orglevel Onjects and values (from the "Normal roles" in the chosen combination). Create company specific derivations from the Orglevel roles.
3rd assign the Normal roles and a OrgLevel variant to the user.
Advantage of this.
a leaks in OrgLevel security when assigning multiple roles to a users are already detected when the Orlevel roles are created.
b try to create as littel as possible OrgLevel roles and the maitenance effort will be reduced dramatically.
Downsite of this:
it takes a lot of effort to initially create the OrgLevel roles and the shuld be thouroughly positive and negitave tested. One must be allert that with every change in the normal roles the associated OrgLevel roles should be evaluated as well.
Good luck you are on the right track
Answer:
Auke,
Your experience is helpful for me!
You mendtion: "2nd create OrgLevel roles (based upon Composites or any other combination of roles that are assigned t users) and fill these with all the Orglevel Onjects and values (from the "Normal roles" in the chosen combination)". I am curious why and how do you combine the OrgLevel came from different generial roles into one OrgLevel role. OrgLevel authrizaiton object is activiry related, can you combine "02-change, 1000-company" and "03-display, 1000-company" into one OrgLevel role? Is there is potencial security problem for a view only user?
"One must be allert that with every change in the normal roles the associated OrgLevel roles should be evaluated as well", the bigger the OrgLevel is, the more evaluation should be done, right?
Thanks
James
Answer:
Create The 20 separate roles and KEEP IT SIMPLE! Maintianing the 20 roles is a cost of doing business and simple and more secure in the long run. You know EXACTLY what your are changing and it will allow you to use PFCG and SU24 configuration more effectively..
Whatever you do has to out-live you as the creater. A tcodes only role matched with an org only role is NOT SIMPLE and will degredate over time and while you may understand it and get comfortable with it, your back up might not and the people following you definitely will not.
_________________
John A. Jarboe
Answer:
John
from experiencing the approach i suggested in a number of BIG implementations we know that it is easy to transfer to other people as long as you understand it yourself.
The OrgLevel roles have to be build manually and yes you can add multiple times the same object with f.i. activty 1 and 2 for a company code and 3 for a wide range of company codes. But the values you need to enter you derive from the roles you want the orglevel roles to cover.
F.i. a composite, then you collect the orglevel obejets with values for all singels.
Btw, SAP knows of our approach and had advised it to other companies as teh best way to avoid a large maintenance effort when using simple derived roles.
This apporach is NEVER going to be a security risk as you will initially ather enter to little autorisations in the orglevel role than to much
Answer:
The simpler the approach the easier and simpler long-term maintenance and the more transferable.
Things to consider
from experiencing the approach i suggested in a number of BIG implementations we know that it is easy to transfer to other people as long as you understand it yourself. I have expreiences many large installations ( Exxon, Texas Instruments, etc) and the simpler the better and the more auditable it is.
The OrgLevel roles have to be build manually and yes you can add multiple times the same object A lot of extra work where a copy will suffice. Also a nightmare when you upgrade ( any type, hot pack, version, etc) and SAP introduces a new auth object that has an org level. you now have to "add manually" where SU24 would do it for you if you configure SU24 correctly and use the org maintenance screen in the role.
F.i. a composite I Never recommend composites, violates Keep It Simple, exposes you to SOX and SOD problems
SAP knows of our approach and had advised it to other companies as teh best way to avoid... SAP recommends a lot of solutions that are not the best practices or leaves the SAP system open to security exposures and increased long-term maintenance.
Examples:
Auth/new_buffering setting by SAP , opens an exposure so you can add access to an id unknow and undetected.
SU24 delivered with critical objest in generic tcodes F_BKPF_BUP, S_BATCH_NAM, S_BATCH_ADM to name a few.
SAP also recommends use of SAP delivered role as a basis for customer roles, These are full of Segregation of duties violations.
And the list goes on.
Just consider, what may be "efficient and quick to implement" may yield long-term maintenance issues and an eventual breakdown of security...
Whatever you implement always keep in mind
1 What risk are you mitigating
2 What is the probability of its occurance
3. What does it cost.
4. Keep it simple.
It could be that By the time you create a tcode role then copy to a org role and then inactivate what is not needed then verify no leakage, you could copy the base role 20 times and be done.
_________________
John A. Jarboe