12-09-2008 10:31 AM
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.
12-09-2008 12:02 PM
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
12-09-2008 12:02 PM
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
12-09-2008 12:13 PM
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.
12-09-2008 12:55 PM
>
> 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
12-09-2008 1:08 PM
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
12-09-2008 1:17 PM
12-09-2008 1:42 PM
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.
12-09-2008 1:52 PM
Generally I'm against "Me too" 's but here I cannot sit back and not thank you for your kind words. Thank you!
Jurjen
12-09-2008 9:24 PM
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
12-09-2008 10:52 PM
> 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
12-10-2008 6:50 AM
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.
12-10-2008 7:28 AM
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?
12-10-2008 8:29 AM
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.
12-10-2008 2:49 PM
Hi Sean,
You are correct, assign the two derived roles to that particular user.
thanks,
Sun