Role design BI ehp1

[Former Member]

hI

we are planning bi secuirty - we are designing BI security for sales organization like billing,booking, sales out etc . we have proposed our design like -when user request ticket -he will provide to security team with end/power/super etc and Region, and Billing, Booking, sales out etc

once we get user request we are going to give one standard role with bisic tcodes(su53,sp02 etc), second end user/power/super role (Restricting infoareas, infocubes), Third billing/booking role (in this we give s_rs_auth analyis role )

and for hierarchy user maintained in the table . whenever user adds in se16 table he will get access to corresponding region (one of developer saying we

can maintain like this . still i have no idea how it works. if any body have worked like this please let me know.

Please suggest this kind of role maintanence is good or any other suggestions for overall design maintenance

[Former Member]

Hi,

What your friend has said is true. You ca nrestrict access thru table level. Your hierarchy design is like that.

If you want to follow different method, then you will end up with more roles .

Plus point : Especially in production go for custom tcode zse16,which gives the user particular table access only.

How it works ?

Just like a giving table access, for eg, ABAP wants to access to mara table.

You will give access to se16,you restrict on auth group.

i.e Se16

S_TABU_DIS:

Auth group : mention the auth group for mara table.

You can check the mapping in table TDDAT.

PS: We had similar problem,i.e we need to restrict users based on cost centers.

For one user,one cost center. Just imagine if you have more users,how many roles u will end up...

Thanks,

Sri

[Former Member]

thanks sri, i got some understanding on table maintenence, as you said if we add a user to a ztable then directly user get particular region.So that we can reduce large numberof role(pfcg+resecadmin roles) maintenence .

if you know any blogs or threads regarding hierarchy in table Please provide me,

Thanks alex, as we are in first phase, sharing my security approach with experts. Even though following SAP best practices, still some doubts, how it works with table maintenance and all . Earlier i have worked BI security creaiting analysis roles (restricting company codes etc) and adding to pfcg (s_rs_auth). Current client, BI developer team saying they are going to design ztable and added users, so that users get acess to region (i.e hierarchy) .

Edited by: raom78 on Jun 26, 2010 7:09 AM

[Former Member]

Hi,

First you find out from your ABAers how many region you need to restrict. If it is less than 30 regions,then go with

role base design concept.

If regions are more,ABABer will create a table in that table once colum will be for users / second colum will be nodes and third colum will be users.

So when user executes the query, based on run time variable .

eg1: LEt say that user1 has access to region1, then at run time he gets a popup screen to enter variable..so he see tha data for region1

Eg2: Let say user 2 ,should have access to region 1 to region 50 ? (consolidated data)

if you follow eg1. then its tedious process for this user to enter 50 region one at a time.

So best option is to maintain it in table. i.e In the table it self they will link which user has to access to which regions.

So at run time you need out need to enter values for variable. See the word doc.

PS: while creating a role for restricting query you have to include the variable, so that at run time the user will will get the correct region data.

No need to give se16 access to the users.

www.bi-expertonline.com/downloads/Smith.doc

http://help.sap.com/saphelp_nw70/helpdata/en/44/4fc09c78ef4e35e10000000a1553f6/content.htm

Thanks,Sri

[Former Member]

Hi,

Without knowing more about your setup I can't really comment on the design, though it is a very common concept used for BI and it won't cause any problems if you have a consistent approach to designing and implementing it.

From what you are describing, it sounds like your developer may be using authorisation variables (a neat concept in BI) to provide authorisation based on some custom logic that they have developed. You should confirm with your developer that this is the case and to provide you their documentation on the solution as you will need to reflect the variable in your role build.