BI 7 power user security question

[Former Member]

Hi,

we have seperate power user roles for business. and we want them to assign authorization for specific tasks -

power user can create Y queries only

they can save as any query but cannt modify or delete any other users query

can create on Y calculated or restricted key figures

can use any variables in their query but cannt create them.

but when user has admin role or any other area in their profile the power user role gets wide open - they can edit/delete other users query also.

Power user role is composite role includes analyst role too...here is detail of Bex component details for power user role -

1) S_RS_COMP

create or generate, change, display, delete, execute for all cubes in that info area for only Y queries

create or generate, change, display, delete, execute for all Y calculated key figures and restricted key figures

2) S_RS_COMP1

change, display, delete, execute for all Y queries for his own userid

change, display, delete, execute for all Y calculated and restricted key figures

Admin roles has is composite role which includes Analyst role in it.

can some one give some info on this issue ?

Thanks,

KS

[Former Member]

Find in which roles the two objects co exist using SUIM

and protect the two objects in all those roles only then you can get your results.

I think few of the roles have * value for the authorization object

S_RS_COMP and S_RS_COMP1

Please look at the definition for these objects

I am pasting the SAP example for S_RS_COMP from its definition, similarly look for S_RS_COMP1 and maintain those values in all the roles which have this objects.

Example

With InfoArea 0001 in InfoProvider 0002, user A is allowed to create, change and delete the queries that start with A1 and A6. The user can change the structures (templates) and calculated key figures already defined in this InfoProvider.

Relevant authorization for user A:

InfoArea: '0001'

InfoProvider: '0002'

Component type: 'REP'

Component: 'A1','A6'

Activity: '01','02','06'

InfoArea: '*'

InfoProvider: '0002'

Component type: 'STR', 'CKF'

Component: '*'

Activity: '02'

[Former Member]

Thanks Frankil -

But i already tried it. not working

I applied -

S_RS_COMP

activity - 01, 03, 16 (currently it is have 01,02,03,06,16)

Ifno area - A1

Infocube - *

Rep Comp. - Y*

type - REP

S_RS_COMP1

Activiyt - 02,03,06,16

Rep Comp - Y*

Type - REP

Owner - $user

but with this change user is not able to do "save as" for any Y* query and which is required.

[Former Member]

Step 2:

Just for test purpose see if you try with * for

REP COMP *

OWNER *

and see if it works.

Before you do that above

Step 1:

Also when it says you cannot SAVE AS

can you take the SU53 on the backend system to see what is failing

[Former Member]

Hi Franklin,

Your suggested option wont work for me -

Rep = * --> we dont want user to edit any reports

User = * ---> and not even for any user. it has to be $user

Also, su53 didnt give me anything coz user is having admin access in all areas if he has admin authorization for one area.

any one can suggest anything to resolve this issue ?

Thanks,

KS

[Former Member]

Hi ,

This was to test if its happening only for Y* ?

without clear information you cannot get results, also if you cannot get SU53 trace the actions and you will be able to find the problem.

[Former Member]

Hi Keral,

Just trying to understand the set up but need some more info. Whats the value of S_RS_COMP1 in the admin role? Also in addition to the power user role, which all roles present with the user has S_RS_COMP1 with activity 02?

Regards,

Aninda

[Former Member]

Hello Aninda,

in Admin role

S_RS_COMP1

Activity: 02, 03, 06, 16

Name of reporting componenet: Y*

Type of reporting componenet: REP

Owner: *

Power User:

S_RS_COMP1

Activity: 02, 03, 06, 16

Name of reporting component: Y*

type of reporting component: REP

owner: $USER

in addition to Admin role user has power user roles in any other areas. again we have restriction at organizational level by info area. also, we have master roles for admin, power and analyst - then we have derived roles from that master roles for all areas. but in all cases the restriction is at organizational level for info areas.

Thanks,

KS

[Former Member]

Hi Keral,

The S_RS_COMP1 access in the admin role is overriding everything else i.e a user with admin role will have change access to queries created by anyone else as long as he has S_RS_COMP for the query as well (which he will get from the respective power user roles)

In your case, one option will be to limit the S_RS_COMP1 access in the admin role. In case the admins do indeed need the full access, create a version of the admin role without S_RS_COMP1 for folks who are also power users. Not sure if this will solve your problem though but the requirements of the admin and power user roles seem to be a bit contradictory to each another.

Regards,

Aninda

[Former Member]

Aninda,

forgot to mentioned that we have restriction at organizational level for info area.

so one user has for eg. ADMIN role for FInance Info Area and has Power user role for Human Resources

he gets admin access as Admin for Human Resource Info area too.

this is the issue....Looks like the restriction is not working !!

Thanks,

KS

[Former Member]

Hi Keral,

From your last reply it appears that you have changed InfoArea to an Org Level?

However, the infoarea field is present in S_RS_COMP. User restriction is through S_RS_COMP1 and since it doesn't have the infoarea field it can not be restricted at the infoarea level. End result being a user with both power user role and the admin role, has full access to update other people's queries for the infoareas in the power user role. Hope this helps and this would probably need you to re-think the design a bit!

Regards,

Aninda

[Former Member]

ok let me be more specific -

we have restriction at organizational level for info area and at the S_RS_COMP level too.

S_RS_COMP

has Activity, info area, info cube, reporting component, type of reproting component restrictions.

hope its clear now - this info i posted in old reply. its big issue not able to fix it.

thanks,

KS

[Former Member]

Having InfoArea as an org level only frees you from having to separately having to maintain infoarea for all objects where it appears as a field. Hence, A restriction for InfoArea at the org level will only be effective for the auth objects which have the InfoArea field in them. S_RS_COMP1 is not one of them. It can not be restricted at the infoarea level. Hence, your problem.

[Former Member]

Hello,

Please refer SNote 540720. Further I suggest you chang enaming convention for queries. HR queries should start with HRxxxxx and FI with FIxxxxxx etc. This way you can restrict users.

Example a user needs Admin rights in FI and power user rights in HR then

in Admin role

S_RS_COMP

activity - 01,02,03,06,16

Ifno area - FI

Infocube - *

Rep Comp. - FI*

type - REP

S_RS_COMP1

Activity: 02, 03, 06, 16

Name of reporting componenet: FI*

Type of reporting componenet: REP

Owner: *

Power User:

S_RS_COMP

activity - 01,02,03,06,16

Ifno area - HR

Infocube - *

Rep Comp. - HR*

type - REP

S_RS_COMP1

Activity: 02, 03, 06, 16

Name of reporting component: HR*

type of reporting component: REP

owner: $USER

Does it help??

[Former Member]

Pankaj,

Thats the way we have our admin and power user role. Except from your COMP1 for admin role which give Owner= *

i didnt get that part? why it needs that? coz by giving reporting comp = Y* and all infocube for given info area is also working fine for admin role.

we have like below:

AdminRole

S_RS_COMP

Activity: 01, 02, 03, 06,16

info area: FI

infocube: *

name of the reporting component: Y*

type of the reporting component: REP

Power User role

S_RS_COMP

Activity: 01, 02, 03, 06, 16

Info ARe: HR

Info cube: *

Name of the reporting component: Y*

type of the reporting component: REP

S_RS_COMP1

Activity: 02, 03, 06, 16

Name of the reporting component: Y*

Type of the reporting component: REP

Owner for: $USER

apart from above we have info area restriction at organizational level too for given roles.

But even though when any admin role combine with any other info area's power user role it gives admin role to all inf areas to all cubes !!

but still it

[Former Member]

Hi Keral,

Organizational level restriction may allow you to restrict based on say company code or plant but you need to devide it based on departments as you metioned. So I am not sure if org level restriction really works here. But you may have not noticed my trick of restrictions. Lets compare it again

Your setUp My Suggestion

AdminRole

S_RS_COMP S_RS_COMP

Activity: 01, 02, 03, 06,16 Activity: 01, 02, 03, 06,16

info area: FI info area: FI

infocube: * infocube: *

name of the reporting component: Y* name of the reporting component: FI*

type of the reporting component: REP type of the reporting component: REP

S_RS_COMP1 S_RS_COMP1

Activity: 02, 03, 06, 16 Activity: 02, 03, 06, 16

Name of the reporting component: Y* Name of the reporting component: FI*

Type of the reporting component: REP Type of the reporting component: REP

Owner for: $USER Owner for: *

In my solution above, it will give User1 full access to all queries starting with FI*

In Following, the same User1 will get full access to his own queries in HR area. So the trick is naming convention of queries which really diffrentiate between departments here.

Power User role Power User role

S_RS_COMP S_RS_COMP

Activity: 01, 02, 03, 06,16 Activity: 01, 02, 03, 06,16

info area: HR info area: HR

infocube: * infocube: *

name of the reporting component: Y* name of the reporting component: HR*

type of the reporting component: REP type of the reporting component: REP

S_RS_COMP1 S_RS_COMP1

Activity: 02, 03, 06, 16 Activity: 02, 03, 06, 16

Name of the reporting component: Y* Name of the reporting component: HR*

Type of the reporting component: REP Type of the reporting component: REP

Owner for: $USER Owner for: $USER