Help Needed. One role for different autorizations.

[Former Member]

Hi, I have been looking for several posts but I'm still confused.

I want to assign one role to several people. So, several people will have access to the same transactions, but... everyone will have authorization to diferent values.

Here, we have 'n' roles. For 10 people, 10 roles, each one with different values, what means that we have our SAP Security full of roles, and when maintenance comes, is a nightmare.

I want to change transactions in just one place, not in every role.

I see that the Derived Role concept seems to suit my goal, but I'm still not sure.

May I do this with just one role?

Please help,

Jose Pinedo

[Former Member]

What you have described will require different roles - if there are 10 people with different access requirements then you'll need 10 roles. That being said, derived roles can work for you if the values that you need to be different are ORG level values. If not the maintenance with derived could actually be more work than having them as just separate roles. It really depends upon what the different values are.

[Former Member]

Hi JC. Thanks for your response.

The values I was talking about were Org. Values and other values. E.g.: a user has to account to a document type but can only see another type, and/or for a company given, can use a Profit Center....

I think that's why I'm so confused.

I can't believe the Authorization Module is so complicated.

There is no other way than create multiple roles for the same transactions? Can't I create one role, and then assign this role to different people (same functions), and assign too a profile copied with different authorizations? I was hoping I could creat profiles manually.

Thanks in advance,

Jose Pinedo

[Former Member]

Yes, you can try that approach. Either create a role or profile with just

the tcodes and then another role or profile with the auth object values,

but at the end of the day as long as you have 10 people with different

auth object value requirements you'll end up with 10 roles or profiles.

Also - this approach will become very difficult to maintain long term since

you are "detaching" the linkages that profile generator provides you by

associating the tcode with the auth objects.

Yes - security can be complex - it depends on your design and your company's

requirements. I always tell people - if you want easy maintenance, give

everyone SAP_ALL and there's little to maintain from a security perspective,

but no one ever takes that route since giving SAP_ALL would be ludicrous.

[Former Member]

Yes, the approach with auth. obj. separated will mean a role for every person, and as you mention, detach the generator with the objects, as mentioned in other posts.

Thanks a lot for your info.

I'll keep looking for a good approach specially for IT personnel.

Jose Pinedo

[Former Member]

Stick with Derived Roles model, especially when they all have access to the SAME transactions. You can uses following programs to create a new Organization Level Field, e.g.: Profit Center.

PFCG_ORGFIELD_CREATE

PFCG_ORGFIELD_DELETE

PFCG_ORGFIELD_UPGRADE

By keeping the link together, even you have 10 derived roles, in the long term, you only "maintaining" one master role. The only time you have to maintain every derived role is you have new Org Fields.

One nice thing about derived roles, you can make an Org Level value "Local". For example, a user have full auth on Company Code A, but display on Company Code B. Keep the Company Code A as the Org Level Object you maintain, make a copy of the Auth Object with company code, change the value of ACTVT to display and Company Code B. Since this field became "maintained", the value of Comp Code B will stay there.

If you detach the tcode & the auth objects, when you add a new tcode, you will need to maintain all roles. You want to think long term.

One word of caution, you will need to run PFCG_ORGFIELD_CREATE in every system.

Thanks,

Lye

[Former Member]

Additional note of caution when creating additional

ORG levels values is that the you have to be certain

that the fields you define will only impact the auth. objects

that you want. For example, defining authorization group would

be an issue since there are many auth objects with this field.

[Former Member]

Hello Jose,

While the suggestion suggested by Tse is good one it has one drawback.

Once you include profit center in organizational values all the roles having profit center would get affected and you will need to modify them accordingly.

Frankly either you must use the derived roles concept which is widely used to solve such issues or create 10 seperate roles. For this you may use CATT to reduce your effort. But this is the best solution in my opinion.

Sometimes the saying No Pains No Gains holds true.

Regards.

Ruchit.

Message was edited by: Ruchit Khushu