Role maintenance of "enabler" design concepts

[Former Member]

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...

[sdipanjan]

Hi,

Are you creating the roles in ABAP stack for FF? or For talking about any configuration related backend roles?

regards,

DIpanjan

[Former Member]

There is no "correct" way as it depends how your concept is structured.

If you have your org values in a separate (enabler) role then you need to make sure the activities for those objects are maintained in the enabler. If you maintain the activities in the master role then you will not have a complete value set for an auth object. If you have an auth object with only field values then you usually maintain it in the master role unless you are using it for other restriction purposes (such as access to posting periods, access to purchasing release groups or codes) where you would maintain this in an enabler.

If you are going down this process then before you build anything you must strictly document exactly how you are dealing with each situation otherwise it will end up in a complete mess like the majority of implementations I have seen that heavily depend on this concept.

[Former Member]

Hi Alex,

Thanks for the reply . u understood ma query correctly...

I m implementing SAP GRC for a manufacturing company.. Creation of roles in the backend has done as per the org structure of the co.

E.G. as per the org structure we have divided the business process in 27 functions say DO, Finance, Planning etc.

Under each function there are master roles and enabler roles.

As u said one auth object will require one complete set of values.. now Say Auth Object V_KONH_VKO generates

Activity -

Division-

Sales Org-

Distribution channel -

Now i have maintained seperate enabler role for each, say for divsion ma enabler role is YE:DO:SALES_INV:DIV

and then for Sales org differnt enabler role. also , not in one enabler role i have maintained all values say if have to give division value as DL, DS,ZS then i have maintaned three enabler roles for divsion. same for sales org 6 enabler roles maintaining values as nort, sout, east , west etc.

so is it right to maintain enabler roles for each field value like i did or should i maintain it as one enbelr role for division and giving all above values in that only??

Regards,

Muskaan

[Former Member]

Hi,

As I said before, there is no correct way of doing it. Both ways will work.

Based on what you have got I would look to combine the "enabling" authorisation objects that support a specific set of functionality e.g. your Master role. You could go one level higher and create enablers for a specific functional area e.g. Sales but the risk with this is that you will give additional access by virtue of more auth objects than is strictly required to support the transactions in your master role. As it is entirely possible to drill through to additional functionality in many SAP tx without invoking an S_TCODE check, it is your call if you want to of this.

Without knowing more about your situation I would say that if you are at this stage in the build I would scrap the enabler concept and use the master roles you have already to create a set of derived roles that match how the company wants it's enterprise structure defined.

Cheers

[Former Member]

Thanks for the suggestion Alex..

Lil confused and i guess i will end up maintaining all values in enabler role..

[Former Member]

What is still confusing you? Let us know and we may be able to help.

An important thing to remember is that there is no default "enabler" methodology - there are lots of ways you can use it as you can with standard SAP functionality

Don't take this personally but if you don't have the enabler concept mapped out and documented 100% before you start the design & build phase then it has a high chance that you will encounter problems:

1. You go live and enter PGLS

2. You handover

3. You are audited

The concept can and does work but the process around it must be absolutely perfect.

[Former Member]

Hi Muskaan,

- The Enabler concept is not widely used or appreciated, as it would require 2 or more roles(against 1) to be given to a user.

- All the values of a field(in your example Division), should not be given in a single role for SOD.

- Creating Enabler role for each field, will produce record(guiness) no. of roles, and hence confusion.

- you cannot keep track of the fields associated with a t-code. So, insufficient roles will be given to user.

let me know, if any doubt.

regards

Edited by: Plaban Sahoo on Oct 11, 2010 12:13 PM

[Former Member]

The structure has been defined by PWC and they r helping urs in implementing GRC.. but i m not comfortable and confident about the mothodology dats why raised the issue...

As u said it should be 100% documented as how so ever we are maintaining values.. wich ids not getting done coz thr is no structured way.. dats why i m confused.

[Former Member]

You are right it should not be given in one role... but the problem is this only mainatining roles for each field value is very tedious and moreover identiification of them later on is a big task..

Say i hav maintained role for division field value ZS.

now while testing i cum to know that Division Ds also i hav to maintain..

Problem - Creating Fresh role then and there.

Maintaining values as required by user. say activity - 1,2,3

Maintaining the same activities for Role ZS also

at times of urgency,, creating and editing so many things will end up in mess only. n dats why i m worrried abt the way PWC suggested.

[sdipanjan]

> You are right it should not be given in one role... but the problem is this only mainatining roles for each field value is very tedious and moreover identiification of them later on is a big task..

>

> Say i hav maintained role for division field value ZS.

>

> now while testing i cum to know that Division Ds also i hav to maintain..

> Problem - Creating Fresh role then and there.

> Maintaining values as required by user. say activity - 1,2,3

> Maintaining the same activities for Role ZS also

> at times of urgency,, creating and editing so many things will end up in mess only. n dats why i m worrried abt the way PWC suggested.

This is the reason why the Master - Derive role concept was introduced. Lets discuss with your example. But before that we need to keep in mind that Derive roles and their idea is not to provide different Authorization values in same set of roles. Rather it is a kind of Geographical segregation only - i.e., the same role (or activity group) is going to be used by same position in across different locations of the enterprise.

Now coming to you example: You first prepare one Master Role and main ALL Authorization Fields EXCEPT Organization Level fields only. The authorization required to perform the actions with this role is now complete totally which will be used in different geographic locations. Perform a SOD check on this set of roles and rectify accordingly. If time permits then go for a Reggration Test cycle on this Master Roles.

In the next phase, go for creating the Derive roles now. You only need to maintain the Organization level fields here as all other fields will be adopted from the reference or master role. So, a big time consuimg effort is saved here. Perform same kind of SOD check against the pre-defined Org. Levels.

For the roles where the Org. level fields are not present but few fields only have different values in between them: You create one role and maintain all fields there. Now during testing phase if you need to create few more almost same role with nominal changes in some field values then COPY the role from the first one and just change or maintain those field only. This will help to save lots of time.

Let us know your view.

Regards,

DIpanjan

[Former Member]

- i do not understand what is PWC(is it some process ...?).

- final suggestion:- Individual roles created on each field value(01, 02), will only create a huge mess.

[sdipanjan]

> - i do not understand what is PWC(is it some process ...?).

PWC: [PricewaterhouseCoopers|http://www.pwc.com/] - one of the Audit Big4.

> - final suggestion:- Individual roles created on each field value(01, 02), will only create a huge mess.

Please check my last post on the suggestion and let us know your view as well how it can be done in a more productive ans Cost-Time effective manner.

regards,

Dipanjan

[Former Member]

> The structure has been defined by PWC and they r helping urs in implementing GRC.. but i m not comfortable and confident about the mothodology dats why raised the issue...
> 
> As u said it should be 100% documented as how so ever we are maintaining values.. wich ids not getting done coz thr is no structured way.. dats why i m confused.

Hi,

You should address the questions to PwC. Like any systems implementer their role design methodology lies firmly with the individual who is given the task of design. Unfortunately who the designer works for is often no reflection on the quality of the design or for that matter a reflection on their colleagues. For the record I am ex-PwC too.

The designers have a responsibility to provide you with the detailed design and guidance that I have been referring to throughout the process. If they do not then raise that with the Senior Manager / Director who is running the team and I am sure that they will work with their guys to remove any area's of uncertainty.

Edited by: Alex Ayers on Oct 12, 2010 1:26 PM

[Former Member]

n dats why i m worrried abt the way ... 

The time will have been more wisely spent teaching you to spell than to build defunct "enabler" type role designs.

Please use proper spelling and avoid "enabler" roles as if they were a pest.

Plausible exceptions are in my opinion www.twitter.com and granular Cost-Center roles respectively, due to their own restraints.

Also do not cross-post and use meaningfull subject titles. is as usefull to us all as 8000 enabler roles will be to you.

Cheers,

Julius

[Former Member]

This is the reason why the Master - Derive role concept was introduced. Lets discuss with your example. But before that we need to keep in mind that Derive roles and their idea is not to provide different Authorization values in same set of roles. Rather it is a kind of Geographical segregation only - i.e., the same role (or activity group) is going to be used by same position in across different locations of the enterprise.

Now coming to you example: You first prepare one Master Role and main ALL Authorization Fields EXCEPT Organization Level fields only. The authorization required to perform the actions with this role is now complete totally which will be used in different geographic locations. Perform a SOD check on this set of roles and rectify accordingly. If time permits then go for a Reggration Test cycle on this Master Roles.

In the next phase, go for creating the Derive roles now. You only need to maintain the Organization level fields here as all other fields will be adopted from the reference or master role. So, a big time consuimg effort is saved here. Perform same kind of SOD check against the pre-defined Org. Levels.

For the roles where the Org. level fields are not present but few fields only have different values in between them: You create one role and maintain all fields there. Now during testing phase if you need to create few more almost same role with nominal changes in some field values then COPY the role from the first one and just change or maintain those field only. This will help to save lots of time.

Let us know your view.

Hi..

U correctly said that it is a kind of Geographical segregation only - i.e., the same role (or activity group) is going to be used by same position in across different locations of the enterprise.

we wanna do like dis..

i m quoting the example here whcih i m doing n along wid it the prob i m facing

Funtion is DO (DEpot Officer)

which has 14 master roles now say MAster role GOODs Inwards has following tcodes

MB51, MB52, MIGO

NOW say tcode MIGO which is the lifelinefor DO id genertes the org level plant where we are maintaining "&" sign signifying restriction on the value dat time and adding it manually later on as plant will differ frm DO to DO

now theParticular TCODe MIGO genertes 10 auth objects say

M_MRES_BWA- which has activity and movement type combi.

PROBLEM- say i hav given mov type 645, 646 to DO ID now while testing i cum to knw HE needs 301,302 n many more so dat time i hav to create say 5-6 roles as per req of mov tym n givng act in each role. same thing for other auth objects i have to do.

is this the way only we can do ??

this e.g. has only two things ativity n mov type whereas thr r many object wich generate many org level say

one auth obj generates activity, division, sales organisation and distribution channel n i hav maintained separe enabler roles for each .prob while testing if i hav to add all things div, sales org and distn so i hav to maintain so many values keeping in mind editing the activity for earlier roles also. i guess i made the discussuin confusing but whether its a prob or a one time exercise i dnt knw

nalso suggest me if the auth object is same n the enabler role is repeating for many master roles so do i need to maintain it in one place or for master role ???

regards,

Muskaan

[Former Member]

Muskaan,

You are asking questions on this forum that the original designers of the concept have been paid to answer. This is their design and because they have deviated from SAP Standard, we have no way of 100% guessing how they have addressed this.

When you contacted the engagement manager responsible for the design, what was his/her response to the lack of documentation? If you have not spoken to them yet then please do not waste the time of everyone here by asking questions that they have been paid for.

They have committed to providing a design that you are very likely to break through not fault of your own due to their lack of guidance. This concept must be watertight if it is used otherwise you will very soon find yourself having to rebuild it once it fails to meet business requirements.

[Former Member]

Hey Alex,

Chill.... i m sorry if i asked the wrong que but i m in a learning stage and not well versed wid the system dats why asked whrevr i faced prob.. n yes i asked the same wid the concerned person but not received appropriate answer..

anyways thanks for the replies so far.. it was helpful..

Regards,

Muskaan

[Former Member]

I'll chill if you don't use text speak...iz dat a deal?

You run a real risk here of screwing up your build badly, not because you are early in your career but because someone else has given you a bad design. If they are not responding correctly then this should be escalated through your IT management to their partner who governs the relationship. If it was standard SAP build method then we could easily help. Because we don't have visibility into their design as a whole, it's virtually impossible to tell you how to do it in a way that supports their non-standard design. It is very possible that someone answers your question in good faith but due to the messy design it can cause problems further down the line. It sounds like you are a Perm - if that's the case then it's you who will have to fix it again anyway so we are trying to save you that pain.

[Former Member]

Its not a deal... n u cud have also escalated by not replying... but the way u replied is not appreciable...

thanks for the suggestions so far.

Muskaan

[Former Member]

I think the chill pill is on the other foot now. If you post up a question for public scrutiny then you have to accept the answers that you get. If someone has this problem in the future, hopefully they will understand that the issue is with the service provider contracted to design their security build and should be resolving it through those channels.

You do yourself a disservice by using idiot speak on a technical forum because from what I can see the opposite is true.

[Former Member]

pls contact security lead of each business.

And create enabler role per business.

org values had to be confirmed by seurity leads,

that is correct process in any manufacturing org.

regards,

Surpreet

[Former Member]

@Muskaan,

I have worked around 3.6 years on enabler conecpt which was designed by PWC.My personal opinion is that enabler concept is very good.

But you need to be very carefull when you design enabler roles.You need to create two types of enabler roles.

one should be for create/change or update and second one should be for display only.even you need to seperate master role like change and display roles.

It would be better to create enabler roles for each sector ex.north,south,east or west.If your company is a global organization, I recommend to create country wise enabler roles.

The maintenence of enabler role is easy if you understand the concept correctly.

if you still have any questions, please let me know.

Thanks

Mohan

[Former Member]

thanks..

ur suggestion of seperating enaler roles for change and display helped a lot..

[Former Member]

Hi muskaan,

I provided some thoughts to you on this question in the [GRC forum|], 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!