Role maintenance of "enabler" design concepts

Question

hi all,
which is the correct way of maintaining MAster and enabler rle in SAP GRC.
As per ma knowledge, T Cdes and activitites we shuld maintain in master role and rest in enabler role. is it right ??
Edited by: Julius Bussche on Oct 12, 2010 6:08 PM
Subject title made more meaningfull...

Answer 1

Hi muskaan,
I provided some thoughts to you on this question in the [GRC forum|Query], but wanted to echo some of the feedback provided here.  For what it's worth, your best bet in this situation is to discuss your questions and concerns with the other members of your security/GRC team - they will be in much better position to talk through your detailed questions regarding your specific situation than any more generic advice you will get on SDN.
As you have heard, the enabler and master/derived concept are 2 approaches for localizing your roles. Up until the point of localization your role build approach will be the same under either methodology following the steps Dipanjan laid out above.  Each approach has strengths and weaknesses that must be weighed for your specific SAP environment and your business and security objectives. Without getting into too much detail, I believe the enabler concept yields the greatest value in environments with very deep and fluid/changing organizational security requirements.  In these situations the enabler concept allows you to more efficiently manage your organizational security when the pure economies of managing derived roles across the security landscape become burdensome. Often times managing your roles not only occurs within your SAP application where they are built, and in these cases you must consider how your localization approach will impact the maintenance of traditional composite roles, CUA composite roles, or even more "virtual composite" roles that group SAP access, but sit outside SAP in a role management, IDM, or other provisioning systems.
Like you have seen, one of the biggest drawbacks of the approach is that it is a non-standard strategy so education, documentation, and knowledge management becomes crucial for its ongoing sustainability. As mohanjani pointed out, it often works out very well when your strategic approach addresses the right business/security concerns and it is implemented in a very structured manner.  On the flip side, it can quickly create numerous headaches if implemented improperly without the correct understanding of the approach or if implemented in an environment where the situational factors do not drive the benefits you wish to achieve from your security design.  As with any security approach, as part of your design and strategy development, it is imperative to not only address the traditional "role build" aspect of SAP security, but also how you anticipate getting those roles to users via your request/provisioning process.
To address your specific question on what fields need to go into your enabler rolesu2026 that will really all depend on your organizational security requirements and your design/build approach - again this is best addressed by those most familiar with your environment & project.  In general, though I am concerned if I understand your messages correctly that you are planning to create 27 different types of enablers based upon your functional areas - I would usually expect to see the types of enablers aligned to your organizational security demands rather than a process area. I would also echo mohanjani's thought that for any type of enabler you really shouldn't be creating more than a functional and display version of that role. From a sustainability perspective it is critical that you do not over-engineer the roles and end up with an overly confusing and complex situation where maintenance and knowledge management is difficult.
On a semi-related note, I am intrigued by the role generator tool SAP developed for their DFPS module and has discussed in more detail in their recent authorization publication.  It seems to be an interesting approach to addressing the economic limitations of managing localized roles in complex environments that provides a good balance to the different design methodologies discussed in this thread.  Unfortunately, it seems to suffer from lack of broad knowledge as well, making it somewhat more of a customized approach.
Best of luck working through your questions and your implementation!