Question:
In our company we have decided to implement role based security .Are there any specific popular strategies or architectures?
Which of them are more effective than others?
Answer:
Role Based Security is defined as: one role containing ALL the access a user needs to perform their Job. Corolary: A user MAY have more than one job where SOD do not conflict, Example: Invoice processor is ALSO an HR Time Administrator. Results: - User has two roles assigned.
It is also common practice to have one cross application common user role that housed all the RFC, Printing, and GUI access,
Answer:
John Jarboe,
By one role, do you mean a composite role made up of all of the related things an invoice processor might do (process a/p, display a/p, display master data), or would you just wrap all that into one role, with lots of transactions?
I am curious, like the first poster, as to what other models are out there besides role based, and if that is indeed, the best practice.
Answer:
On SINGLE non-composite non-clever all encompasing simple manageable role .
NEVER composite anything.
The Idea is to Keep it Simple, auditable, and minimize maintenance.
Your SOD's will dictate the list of tcode to some extent, and an invoice processor would NEVER have master data maintenance.
Not also the logical extensions of tcode should be added. Example. If i create I probably need to chagne the mess I made and display it.
If i Change ( and npot create) I will need to display.
Answer:
An authorization check (when present at all for sufficient control) does not care where it is in your fancy construct of single and composite roles and urban legends about profiles and how SAP works.
If the authorization is checked, and found, then it "works". No matter which profile and role which generated it is causing the authorization check to not fail.
Try to construct a role based on transactions at a level which is as high as possible in the org chart, and as low as possible in the amount of roles (and ultimately profiles) required.
The devil is in the detail, but SAP complicates it further into profiles.
You can compensate for this by keeping the amount of roles simple and avoiding the fancy stuff, particularly when you know that you are actually not very good at testing your design...
Ned
Answer:
John and Ned thank you for the information.
What are role based security design strategies in portal based environment. What are the special concerns? Is there is any difference in implementation from the regular role based environment
Answer:
Only the Role baming convention is important as the portal sorts by TECHNICAL name of th erole fo if you want the generig user stuff to ne at the botto,m then the role need to be XA:GENERAL_USER where the Invoice processor would be FI:AP_INVOICE_PROCESS then the menus sort with the FI role fist and the genreal access on the bottom.