04-16-2009 6:44 PM
Hi,
Need your help in understanding SAP Security Role design in R/3 4.6. I was thinking of an approach where I can have two types of roles in SAP. Role Type A which contains T-codes and does not have org values maintained (left as ""). And role Type B which has all the auth objects in all the roles of type A. Now in these type B roles, I am maintaining display activity and not change along with org values as * (full authorization).
If I grant both roles to a user, and try executing change access for the user, I get an error, "You are not authorized for Company Code ****".
We do not have composite roles in SAP systems. Please advise how this approach can work.
04-16-2009 7:01 PM
Hi Vishwas,
Not sure on the reason for the approach.... however if you understand how security works, then maybe you can go the orthodox and proper way.
The way security works is, the generated profiles give the user authorizations. Authorization in SAP is additive, yes, but its true for an instance of that authorization object with the values maintained in it.
Say you have S_TABU_DIS with activity 02 and open qoutes ' ' in auth group in role A.
Role B has S_TABU_DIS with 03 and SS.
you assign both roles to the user, the user will not get 02 for auth group SS. Because S_TABU_DIS has a different authorization in role A and a different one in Role B.
Read this Thread:[ Authorization Vs. authorization object |;
Are you using derived roles ?
Thanks
Abhishek
04-17-2009 4:44 AM
The simple solution is implementing derived role concept,.
Assign only derived to the users where the Org values have been maintained properly.
Please dont assign parent role with combination or Derived role which gives full access to all Org values
.
04-17-2009 7:25 AM
> Please dont assign parent role with combination or Derived role which gives full access to all Org values
That totally depends on the contents of the organizational fields of the parent roles. That doesn't necessarily have to be a *...
04-17-2009 8:04 AM
in the past we build such a concept for <removed_by_moderator> and worked perfect.
However the spilt between T-code access and other object is difficult to maintain as a thourough analyses is needed to know what objects to assign in the orglevel access role.
In the T_CODE role we assigned DUMMY ' ' value to all org level fields.
it works and overcomes to wide orglevel access because of wrong values in a role assigned to a user overriding the restrictions in an other role
Edited by: Julius Bussche on Jul 21, 2009 10:46 PM
Customer specific information removed.
04-20-2009 12:58 PM
Hi,
The best way what I have seen in the last 8 years is working the way SAP designed it for you. The two layer model with composite roles, roles and derived roles. If you split the organizational values in separated roles it can give a lot of trouble when some one who have not that much knowledge but has followed the amd940 course has to work with it. Believe me I have seen it.
If you work with what I call organizational roles you have to do this on composite level, because it also can have non organizational fields that needs a particular value at composite role level.
So don't be that hard on yourselves and use the SAPway.
Look in the forum, there are more of these questions and meaning full answerers.
have fun
Bye Jan van Roest
07-21-2009 5:55 PM
Thanks Abhishek for the explaination!
Dont know in what context are you refering derived role.
Yes I use derived role as of now, with full authorization for Parent and restricted values for derived role.
07-21-2009 5:57 PM
Thanks Hari!
I do understand the fact for combination of Parent & Derived roles.
07-21-2009 5:58 PM
Thanks everyone for your thoughts!
I guess it cannot be implemented in this way!
I am marking this question as answered!
07-21-2009 9:12 PM
Hi Vishwas,
Sure it can be implemented that way. The problem is that 90%+ of those implementations go very wrong. The other 10% are very efficient until the there has been a high turnover of staff. If you use a product such as Securinfo (if they are still running) then that will automate a lot of the solution for you. The biggest problem is that this method requires lots of discipline and very good understanding of SAP Security, both of which are not always easy to get.
07-21-2009 9:46 PM
> I guess it cannot be implemented in this way!
Perhaps you meant to say that "I guess it is not a good concept to implement this way in the long run"?
If SU22 proposals dont fit your concept based on the choice of tcode, either reconsider the choice or change SU24.
You will anyway reach a limit for the org levels before you reach the tcode limit, and might want to reconsider which fields you are using as org levels.
The best way in my opinion is to keep the link to the menu object (not only limited to tcodes) because it is navigable and "makes sense" to PFCG. The alternate option is reading all the implementation documentation and delta documents, etc....
Cheers,
Julius