Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Reg derived roles combination into composite role

Former Member
0 Kudos

Dear All,

We have a role called GR Clerk. This will be available across all stores and DC for our retail customer. We have devised a strategy wherein we will create one global role with * in org level for site. Then we will

create derived roles for individual DC and stores (from global role) and maintain site for each derived role.

Now our customer wants following:

Example: Store 1's GR clerk shall have required authorizations on transaction for Store 1, plus, one

additional authorization/transaction for Store2.

What we initially though that we will create two individual global roles: One for all authorizations and

second for additional authorization.

Global GR Clerk role: GRC

Transactions: t1, t2, t3

Global GR Clerk role: GRC_additional

Transactions: t4

Derived Roles

for GRCStore1:

1. GRCStore1 with org level Site= Store1

2.GRCStore1_additional with org level Site= Store2

Now I will assign both derived roles to user who is GR Clerk on Store1.

Is this approach correct?

Also, customer wants that only one role should be assigned to user. So shall I create a composite role out of 2 derived roles?

Will the respective site org levels be maintained after combining derived roles into composite one?

Thanks for your time in advance.

regards, Sean.

1 ACCEPTED SOLUTION

RainerKunert
Active Participant
0 Kudos

Hi,

whether your approach with two different roles is correct depends on the authorization objects used for the transactions.

Example:

Transaction t1 needs access to company codes (let's say M_MSEG_LGO with activity 02 and store A). Transaction t4 (second role) needs the same authorization (M_MESG_LGO with activity 02 but store B).

If you combine both roles you can with role 1 and transaction t1 also access store B (if there are no other authorizations necessary).

The segregation into two roles may not be sufficient. It depends on the authorizations included in the roles. You have to keep that in mind and check carefully.

If you want to merge both roles into one composite roles, you have to create the derived roles first. Then put the derived roles into the composite role. Composite roles do not contain any authorizations!

Regards

Rainer

13 REPLIES 13

RainerKunert
Active Participant
0 Kudos

Hi,

whether your approach with two different roles is correct depends on the authorization objects used for the transactions.

Example:

Transaction t1 needs access to company codes (let's say M_MSEG_LGO with activity 02 and store A). Transaction t4 (second role) needs the same authorization (M_MESG_LGO with activity 02 but store B).

If you combine both roles you can with role 1 and transaction t1 also access store B (if there are no other authorizations necessary).

The segregation into two roles may not be sufficient. It depends on the authorizations included in the roles. You have to keep that in mind and check carefully.

If you want to merge both roles into one composite roles, you have to create the derived roles first. Then put the derived roles into the composite role. Composite roles do not contain any authorizations!

Regards

Rainer

Former Member
0 Kudos

There does not seem anything wrong with the appraoch, the question that comes to my mind is why not have the fourth tcode t4 also in the same role and maintain values for the object that may pop up for it speerately with org level as store2 in the object.

I can quote an example here say you want the clerk to create sales orders va01 for store 1 and display sales orders va03 for store 3. The objects can be mainatined accordingly.

Or you can dispense with teh concept of derived roles completely and consider the concept of build method for the role with one role having tcodes and another with the org element objects. you can combine them together in a composite role.

There is an interesting discussion relating to role design concept where our experts have quoted many valid inputs.

0 Kudos

>

> Or you can dispense with teh concept of derived roles completely and consider the concept of build method for the role with one role having tcodes and another with the org element objects. you can combine them together in a composite role.

>

> There is an interesting discussion relating to role design concept where our experts have quoted many valid inputs.

That is a very diplomatic way of putting it

0 Kudos

Hello Alex,

I have been posting in this forum for the past one month and have been regularly checking on the replies sent by you, Julius and Jurjen. The amount of knowledge that I have gained in this period from the tips and suggestions posted by you people is tremendous and I am really thankful to you all for this.

I have also been posting in other forums like MM & PLM but I have not seen a forum so well managed as the security forum.

Thank you very much.

PS:I could not find a space in the SDN security forum where I could have posted this....probably Julius can delete my reply if he finds it irrelevant

0 Kudos

Thanks Subramaniam

0 Kudos

Thanks for the kind words, there are lots of people on here with a huge amount of knowledge and experience in all different areas of security.

0 Kudos

Generally I'm against "Me too" 's but here I cannot sit back and not thank you for your kind words. Thank you!

Jurjen

0 Kudos

Hi,

Regarding the transaction roles and authorization roles, it is also a good approach, however, you would still have to consider the above point in case the authorization objects overlaps and make sure that both are restricted to appropriate "stores".

Whether it's a good approach or not, per me, depends on the overall scenario and the fact that how much maintenance would be required in long term.

Like say, if it is a case that the transaction codes (t1,t2 and t3) are for specific stores and transaction t4 is like display activity of other store and not just store 2. Then creating a common role for transaction t4 and including it in the composite role apart with the store specific role with tcodes (t1,t2 and t4) would also be a good approach.

ZZZ:STORE_CLERK_STORE1 (Composite Role)

ZZS_STORE_CLERK_STORE1 transaction code t1, t2 and t3

ZZZ_STORE_CLERK_STANDARD transaction code t4 (Either no org level restriction or all store access)

ZZZ_STORE_CLERK (Parent Role)

ZZS_STORE_CLERK_STORE1 Org level Restricted to Store 1

ZZS_STORE_CLERK_STORE2 Org level restricted to Store 2

and so on

PS: Naming convention are for illustration only

Cheers !!

Zaheer

Former Member
0 Kudos

> Also, customer wants that only one role should be assigned to user.

I think that customer might have been reading some success stories about using single roles only.

Or they are preparing to do SoD analysis at the level of role name only...

Composite and Derived roles have their place but there are restraints... I smell a rat here...

Derived roles: Usefull for when the business processes are the same and only org level variants are wanted to be replicated => you are inflexible.

Composite roles: Your single roles are built at a level which has lost it's relation to the business process (the menu, and the SU24 data), or you only want the menu.

Mixing inflexible intentions with flexible "quick fixes", to be able to call it "one role" seems like a contradiction to me.

Do any of the project slides mention harmonizing business processes?

Are the Chart of Accounts being harmonized as well (or not)?

Cheers,

Julius

0 Kudos

Dear All,

Thanks a lot for your answers.

We do have harmonized business processes but only for finance and controlling areas. For Inbound/Outbound, different processes & roles exist.

Also, just to clarify things, we'll have 3 company codes and around 1500 Sites. We will also have org levels like purchase group, sales organisation and purchase organisation.

From discussion above, I assume for FI/CO, the concept of global and derived roles would work.

But what abt others? There are a lot permutations and combinations as per customer for each individual user with no similarity across company codes.

@Subramaniam Iyer

By maintaining both set of authrizations along with company codes/sites, will need me to alter auth objs for each derived role, and thereby for each user. But if I restrict changes to org level, maintenance will be a lot easier. Am I correct?

@Zaheer

I have been thinking on same terms like you did.

ZZZ:STORE_CLERK_STORE1 (Composite Role)

ZZS_STORE_CLERK_STORE1 transaction code t1, t2 and t3

ZZZ_STORE_CLERK_STANDARD transaction code t4 (Either no org level restriction or all store access)

The above had been on my mind. But our "customer" wants us to deliver one role/user. They dont want multiple roles for same activity group. Here's where we're stuck.

regards, Sean.

0 Kudos

Hi Sean,

Yes maintenance would be lot easier if you were to maintain orgainzation levels via the org levels button which would thereby reduce the pain of searching for the objects for the store2 specifically.

But, this can only be achieved by seperate roles, I suggested the above as the client was very particular about a single role.

> They dont want multiple roles for same activity group.

Have you questioned the client why he has such a requirement?

0 Kudos

Hi,

I never knew a client who wants to know how many roles we will be creating, specially when they don't have my counterpart in their team.

regards, Sean.

sreekanth_sunkara
Active Participant
0 Kudos

Hi Sean,

You are correct, assign the two derived roles to that particular user.

thanks,

Sun