Best practices / preferred usage of SAP standard (delivered) roles

[Former Member]

Dear Experts,

When going about designing roles for a new system, what is the preferred usage on SAP standard/delivered roles? I was thinking of using them as a "base", then tweaking auth objects here and there to make the roles work but the more I work with them, I find it may be better to create roles entirely from scratch. A lot of the time, I find a lot of inactivated auth objects or objects that seem to not really be needed when looking at the t-codes offered in the menu (S_TCODE).

In that case, I figured it might be cleaner if I started creating roles and adding t-codes via the Menu and maintaining only the auth objects that are proposed in PFCG (and adding a few if necessary).

Do people typically build their roles around these the standard SAP role set or is it preferred to create your own and only use the SAP standard roles as reference (i.e. the t-codes offered in the menu, etc.)?

Thanks for any insights!

[sdipanjan]

> When going about designing roles for a new system, what is the preferred usage on SAP standard/delivered roles?

Those are provided by SAP as a reference so that you can consult with the Authorization Structure of a Standard Position / Task for which you are going to create your own role. For e.g. what are the TCodes, values of Objects should be given to users for their tasks.

I was thinking of using them as a "base", then tweaking auth objects here and there to make the roles work but the more I work with them, I find it may be better to create roles entirely from scratch.

Absolutely! Please do not use SAP delivered roles for you use and also don't try to alter any values.

A lot of the time, I find a lot of inactivated auth objects or objects that seem to not really be needed when looking at the t-codes offered in the menu (S_TCODE).

>

> In that case, I figured it might be cleaner if I started creating roles and adding t-codes via the Menu and maintaining only the auth objects that are proposed in PFCG (and adding a few if necessary).

>

> Do people typically build their roles around these the standard SAP role set or is it preferred to create your own and only use the SAP standard roles as reference (i.e. the t-codes offered in the menu, etc.)?

>

Yes.. as reference.. as you say..

Regards,

Dipanjan

[Former Member]

We create new roles using a list of transaction codes provided by the functional/business teams. Based on that list we create each new role. This does not mean that SAP delivered roles are not looked at. Some times they provide a good starting point for your new roles. They get copied to Z (or Y) roles and then taken through the same process as the firstones. In our case we have a control in place that stipulates thet ALL the content of each role has to be apporved by the role owner, so from scratch or by copying a delivered one, the new role's owner will have to revierw the tcodes and approved them, before the role is transported out of DEV.

Hope this helps.

Juan.

[Former Member]

Hello,

SAP's recommendation is to copy the standard roles into your own name space and make modifications to the copies as needed. I wouldn't go as far as calling it a best practice, but it's certainly doable.

What you need to figure out are your business requirements and run a gap analysis against what SAP standard roles can do.

Most projects I've seen or worked on started from scratch. There's plenty of tools and accelerators that can help you accomplishing this. By far best practice is to engage a SAP Security consultant who's done it before.

Regards,

Matthias

Edited by: Matthias Hessler on Aug 4, 2009 11:32 PM

[Former Member]

My understanding is that the standard roles are relics from testing the applications developed by SAP.

So they are a useful indicator for the requirements of what the application should make possible to control via roles and how the transaction work.

If you read the documentation on the system profile parameter auth/authorization_trace and the difference between a CUSTOMER and a SAP transport/type system and why the "check" values exist in SU22, then you will understand what the standard roles are trying to tell you.

Cheers,

Julius

ps: Just for the record: SAP standard delivered profiles is a different topic. I don't recommend touching those (except deleting SAP_NEW each time it is updated by SAP...)

Edited by: Julius Bussche on Aug 5, 2009 12:26 AM

[Former Member]

@Julius: I remember back in the days (with PWC) we used to work with SAP developing standard roles for different industries. Most of these are still in ECC. So I don't concur that they're relics from testing.

A thing I used to tell customers was that if you go with pure IDES and don't customize anything for your company than the standard roles should work (not realistic, I know). But if you want run fits and gaps against config you should threat the roles the same way. Ultimately starting from scratch (using the business requirements and security standards as input) isn't that hard.

Regards,

Matthias

Edited by: Matthias Hessler on Aug 5, 2009 3:03 AM

[Former Member]

That would explain some of the "manually" and "changed" authorizations in some standard roles..

But seriously, those which are built from the SU22 data and the auth/authorization_trace mechanism are to my knowledge delivered with the system as an indicator how to build a role for an application based on what the original requirements were for it.

Standard delivered roles with the intention that the customer should use them "as is" without any fuss and not much config is what BusinessOne aims to achieve IMO.

Cheers,

Julius

[Former Member]

Thanks for all the feedback. It does seem like the general consensus is to use the standard/delivered roles as a reference to the sorts of t-codes/authorization objects required and to create new roles from scratch. I will proceed in this direction then!

[Former Member]

I find that the standard tech roles are often useful to refer to but can't say that I look at the standard functional roles until further on in the design phase. The reason?

The design and build is dependent on so many things that you have to have a whole load of questions answered before you even start to pull transactions together.

e.g. landscape, current design and use (if any), role & user administration/maintainance setup, business input to role design, high level restriction requirements etc, etc. This will all shape how you conceptually want to build, whether it at task level, job level, using derived roles, using value roles, using composite roles etc. There is a place for all of it but the analysis has to be done first.

Picking up the SAP Standard roles as templates straight away can prevent a lot of that analysis being done as they are there & copies of them can be tweaked to give what is needed.

Where I find them useful is to give some suggestions about supporting transactions, though after doing it for a few years you pick up most of them.

From an organisational design perspective, users should only be running transactions which they are trained on and are in a central transaction repository where the guides are etc. The standard roles contain lots of transactions which do different things, so care needs to be taken to cut out exactly what you don't want.

[Former Member]

Alex, that's very well said. I did find the standard roles to have a plethora of transactions that the end users were not trained on and will probably not be using so I'm using them more to look into the menus to see what transactions are being offered. It should be much cleaner for me to build the roles from scratch after the initial design.