Lousy role design

[Former Member]

Ok, We have a bad role design ... what i mean by it is .. the single roles are tied up to the composites and they did not do a good job with it, for example a single role is given to a user several times because it is in several composites ... but unfortunately on the face of it it shows that it works very well, and the composites are tied up using a custom table through which provisioning is done! ahh its a mess!

My question is - what are the side effects of this bad design ,,, i want to change it .. but i want to give concrete reasons before i start the effort.

[jurjen_heeck]

> My question is - what are the side effects of this bad design ,,, i want to change it .. but i want to give concrete reasons before i start the effort.

Well, this looks like you want to 'sell' a redesign within the company and I'll never buy a car from a salesman who says the car I own now is crap. So I think you should focus on the benefits of proper role design.

The biggest one I can see is that once you adhere to SAP standards far more people can maintain users and roles at your site. No need for custom training as anyone with the proper SAP training will be able to do the job. This also eliminates the risk of some consultant from the outside destroying your current concept by accident, which I think is a real risk.

Another advantage will be: Less problems when upgrading and/or adding support packs.

That's just for starters. Let's see what the others have to add.

[Former Member]

Hi

Just an addition to Jurjen Heeck reply, the bad design causes

1. Increase the security changes in the system

2. Unwanted accesses to the users, which will effect system and data.

if you are thinking to restructure the security my proposal would be below

Create Positional roles (This can also called as composite role, this can be created based on the positions in the landscape) this will contain, 1) Menu roles (Will have the access to T-codes, authorization objects, note if there are organizational level values to be maintained keep a dummy value) 2) Organizational roles (This will be having access to the organizational values, this will help to restrict the user for accessing data of other depts which he /she not suppose to)

I found that if we follow this process, The users will have 1 positional role which will cater all the day to day access in SAP and one general role which provides access for SU53, SBWP etc, This may simplify the security (in terms of user assignment)

Many Thanks

P.

[Former Member]

>

> 
> Create Positional roles (This can also called as composite role, this can be created based on the positions in the landscape) this will contain, 1) Menu roles (Will have the access to T-codes, authorization objects, note if there are organizational level values to be maintained keep a dummy value) 2) Organizational roles (This will be having access to the organizational values, this will help to restrict the user for accessing data of other depts which he /she not suppose to)
> 
> I found that if we follow this process, The users will have 1 positional role which will cater all the day to day access in SAP and one general role which provides access for SU53, SBWP etc, This may simplify the security (in terms of user assignment)  
> 
> Many Thanks
> P.

I have found in many cases that if you follow that process. you will usually end up with an unmaintainable mess far faster than sticking with the original design.

[Former Member]

While I agree with most of what Jurjen is saying, if you can clearly articulate why the existing design is bad, how it can be improved and tangiable benefits for a re-design, then plenty of people will go with the recommendation.

[Former Member]

Hi,

You may not face any problem for it.. But definitely this should be avoided.. Problem like, maximum limit of profile can be exceeded due to huge number of repetation of roles.. Then no more roles can be assigned to the users..

By proper role design this repetation can be avoided as wel as many number of composite role assignment also can be avoided..

Try to make a common role what is getting repeated.. create a sepatare composite role.. and remove the single roles from all the composite roles..

Regards,

Sandip

[Former Member]

To design a maintainable, re-usable and self-documented concept in the system you need to keep the relationship between the objects in the menu design (Menu tab) and the authority to also use them (Authorizations tab) with the intended restrictions.

If you break this, then you are always heading in the direction of a mess and extra-overhead sooner or later.

In the case of composite roles, you additionally add a layer of abstraction between the menu confusion and the authorizations mess behind it so that it becomes just as unauditable as it is unmaintainable. Actually the size of the mess can be hidden for some time until it reaches the famous limit of maximum profiles and authorizations assigned to users for objects other than S_TCODE.

My advise: Find out who the author is of the current concept and how much they know about SAP security. It cannot be excluded that they think this design is "the best" or want to keep it that way in management's eyes... That is how many potential enemies you will have.

Then go to the solution architect (or SAP program manager, or System owner, what ever it is called there) and find out when the next upgrade is planned for (don't bother with Support Packs in this case). That is how much time you have.

Cheers,

Julius

ps: Also take a read through some of the discussions included in the "FAQ & memorable threads" post at the top of the forum. Several of them touch on this topic and opinions vary.

[Former Member]

Thanks all for your suggestions, Greatly appreciated!

I already prepared my proposal to bring some changes ... will keep yall posted.

Yes We can!!!