Promoting S_RS_AUTH to Org Level

[former_member318517]

Hello all,

Just wondering if anyone has done this. Kicking around the idea of using a derived role approach in BW with the children being different Analysis Auths with S_RS_AUTH ( in particular BIAUTH ) as a promoted Org Level.

Thanks,

Tom

[Former Member]

Better than KOSTL in ECC, that's for sure...

You should still try to reduce your number of roles and be on guard for other non-org. levels which the same roles might need down the line.

I would give it an experimental try based on your metrics (users, BIAUTHs, etc) and work out where the pain-ponits might be.

Three of them (which hurt most) will be:

- you cannot maintain BIAUTH in SU24 anymore for any tcodes, RFCs or services.

- you cannot use the same field differently in other objects of the same role.

- you are restricted in the number of authorizations you can create in a single role.

Interesting question...

Cheers,

Julius

[former_member318517]

Good points Julius. I'll have to look further into the impact of promoting that. The reason I and thinking of promoting is that in our BW system we have say a Level 1 role with Analysis Auths (AA) that grant access to the queries and standard characteristics. With that Level 1 role we also have to assign a Plant/Sales Org/CompCode..etc specific Level 2 AA role.

I'd like to promote BIAUTH, put the Level 1 AA in the parent and then modify the children to also include Level 2 AA so we have just 1 role to assign and not 2. Manager does not want composites.

Thanks,

Tom

[Former Member]

I like your manager

Whether you use org level or SU24 is the question.

In SU24 it is sometimes usefull to create symbolic tcodes for "things". This makes activity type merges (and unmerges...) easier for repetitive values used accross large numbers of roles.

Much the same as derived roles, but without the hassle of non org fields. You can try to drive as much as possible in your single roles via the menu and tcode SUPC is your best friend.

Another consideration: how many roles do you already have with BIAUTH as non org field? And why were they kept single and differentiated?

Cheers,

Julius

[former_member318517]

I inhereted the design from a previous consultant. I do not think it is a bad design, I would just like to reduce the number of roles that are assigned to an end user from 2-3 to 1.

Not too sure I understand your last post but the theory of the original design was to create a Level 1 role which would have the queries in the menu, the S_RS_COMP etc auths for the InfoProviders and BASIC Analysis Auths for the cube and certain standard characteristics. You would assign that role to a user along with a Level 2 role which would only contain the object S_RS_AUTH with an AA for say a specific plant(s), Company Code(s) for those queries in the Level 1 role.

I want to promote BIAUTH so that I can put all the Basic AA for the cube in the parent, then derive and modify the children with the specific Org Level AA. I'm just trying to figure out if promoting BIAUTH will come back to haunt me in some manner.

Regards,

Tom

[Former Member]

Hi Thomas,

I dont really think that you can reduce the # of roles that you are assigning with making S_RS_AUTH as an org level entry. Here is what I feel:

1. The folder/BEX roles that you assign to the users are no where relates to the roles that contains S_RS_COMP/COMP1. So these should be assigned seperately.

2. The roles that contains S_RS_COMP/COMP1 along with S_RS_AUTH should be assigned in which you differ the AA with respective Sales Company etc. should also be assigned.

Since the AA that you are adding in S_RS_AUTH are different and are based on the Sales company, plant etc., you have to create indiviudal roles and assign them to the user.

Even though you promote the S_RS_AUTH, the same # of roles should be generated/derived.

Hence, promoting S_RS_AUTH to org level doesn't make any big difference.

Regards,

Raghu

[Former Member]

I've used it successfully on a couple of implementations where it works well to support a modular concept (e.g. separate the menu content from technical auths (generally user / superuser) and data auths.