BI--SAP BI的权限管理

源地址 ：http://silverw0396.iteye.com/blog/229274

一、sapBI的用户分类

There are different types of users in SAP BW. Most of your users will be the users who execute queries and workbooks. These people could be considered "reporting users" or "end users."

There are also users who develop new queries. Some people may
refer to them as "power users" or "data analysts." The users who develop
queries may also create new workbooks and may be responsible for
publishing that information to the right audience.

Then, there are users who create new objects like InfoCubes,
InfoAreas, and InfoObjects. They also schedule data loads, create update
rules for InfoCubes, monitor performance, and set up source systems.
The users who do these tasks are normally referred to as "administration
users."

二、用户权限分类

In an SAP BW system there are two different types of authorization objects.

1. Standard authorization objects: This type of authorization objects is provided by SAP and covers all checks for e.g. system administration tasks, data modelling tasks, and for granting access to InfoProviders for reporting. For this type of authorizations the same concept and technique is used as in an SAP R/3 system.
2. Reporting authorization objects: For more granular authorization checks on an InfoProvider’s data you need another type of authorization objects defined by the customer. With these objects you can specify which part of the data within an InfoProvider a user is allowed to see.

三、关于Reporting authorization objects的对象描叙

S_RS_COMP: Authorizations for using different components for the query definition. This authorization object is very important for reporting <o:p></o:p>

The authorization object S_RS_COMP restricts query component activities. For example, it restricts if someone can create queries, change queries, or execute queries. You can restrict query creation, change, and execution by the InfoArea and InfoCube. If your company has one InfoCube for sales information and another for financial data, you can restrict a user to only those queries written for the sales InfoCube or the financial InfoCube. <o:p></o:p>

You could also use S_RS_COMP if you want to protect by query name. For example, you have an InfoCube for sales data. Every sales manager needs access to this InfoCube. However, sales managers in different lines of business are not allowed to execute the same query. <o:p></o:p>

The following table contains specific information about the fields in S_RS_COMP and how they are used. <o:p></o:p>

<v:shapetype o:spt="75" coordsize="21600,21600" filled="f" stroked="f" id="_x0000_t75" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t"><v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path o:extrusionok="f" o:connecttype="rect" gradientshapeok="t"></v:path><o:lock v:ext="edit" aspectratio="t"></o:lock></v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" alt="bw_auth_obj11" style="WIDTH: 311.25pt; HEIGHT: 436.5pt"><v:imagedata o:href="http://www.sapsecurityonline.com/bw_security/bw_security_authorization_objects_clip_image002_0000.gif" src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image001.gif"></v:imagedata></v:shape><o:p></o:p>

<o:p></o:p>

S_RS_COMP1: Authorization for queries  from specific owners. This object is new in SAP  BW  3.0. It can be used to limit, by the query owner, which queries a user can see. For example, you can only see queries created by the power user for your area.<o:p></o:p>

Authorization object S_RS_COMP1 secures the list of queries seen by the user via the BEx Analyzer or Web-based reporting (this authorization object began with release 3.0A).With S_RS_COMP1, you can limit the list of queries by the query owner. For example, you are a manager for a local sales team. You can only run queries created by the power user for your geographic region. S_RS_COMP1 limits both what queries you can see in the BEx Analyer tool, what queries you can display, and what queries you can execute. The Owner field in S_RS_COMP1 works in conjunction with the fields
in S_RS_COMP.
If the special value $USER is entered as an authorization value for the Owner field,
then a user can only change their queries and cannot change any other
queries. The $USER will also limit the queries the user can see and
display in the analyzer tool. <o:p></o:p>

Authorization
objects S_RS_COMP and S_RS_COMP1 are evaluated together. A user must
have access to both objects. The actions you can take related to a query
in S_RS_COMP are complemented by the owner field in S_RS_COMP1.
<o:p></o:p>

The following table details the fields in S_RS_COMP1 and how they are used. <o:p></o:p>

<v:shape
id="_x0000_i1026" type="#_x0000_t75" alt="bw_auth_obj12" style="WIDTH:
311.25pt; HEIGHT: 234.75pt"><v:imagedata
o:href="http://www.sapsecurityonline.com/bw_security/bw_security_authorization_objects_clip_image004_0000.gif"

src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image002.gif"></v:imagedata></v:shape><o:p></o:p>

<o:p></o:p>

S_RS_FOLD  Display authorization for folder. This object is new in SAP BW 3.0 <o:p></o:p>

If you do not want InfoAreas to
appear as an option, then use the authorization object S_RS_FOLD. This
object is not required. You only need to use it if you do not want users
to even see the InfoAreas listing of queries. The object has one field - Hide .Folder. Push button. If this field is set to X (True), then the InfoAreas button will not appear in the BEx Analyzer Open → Queries dialog box <o:p></o:p>

When
a user brings up the BEx Analyzer or uses the Query Designer for
Web-based reporting, there are four categories from which they may
choose existing queries: History, Favorites, Roles, and InfoAreas. Authorization object S_RS_FOLD will allow you to disable the InfoAreas category <o:p></o:p>

四、SAP BI的管理对应的权限对象权限<o:p></o:p>

S_RS_ADMWB: Administrator Workbench - Objects <o:p></o:p>

Protects
working with individual objects of the Administrator Workbench: source
system, InfoObject, monitor, application components, InfoArea,
AdministratorWorkbench, settings, metadata, InfoPackages, and
InfoPackage groups. <o:p></o:p>

This
object is used throughout transaction code RSA1. It covers many
administrative tasks. It includes dealing with source systems,
InfoObjects, InfoPackages, master data,
and transaction data. <o:p></o:p>

Authorization
object S_RS_ADMWB is the most critical authorization object in
administration protection. When you do anything in transaction code
RSA1, object  S_RS_ADMWB is the first object checked. There are two
fields in this object: Activity and Administrator Workbench Object. Each of the two fields can have a variety of values.
The possible values for the Administrator Workbench field are:<o:p></o:p>

• SourceSys: Working with a source system <o:p></o:p>
• InfoObject:Creating, maintaining InfoObjects <o:p></o:p>
• Monitor: monitoring data brought over from the source systems <o:p></o:p>
• Workbench: Checked as you execute transaction code RSA1 <o:p></o:p>
• InfoArea:Creating and maintaining InfoAreas <o:p></o:p>
• ApplComp: Limiting which application components you can access <o:p></o:p>
• InfoPackage: Creating and scheduling InfoPackages for data extraction <o:p></o:p>
• Metadata: Replication and management of the metadata repository <o:p></o:p>

The following list shows possible values for the Activity field.
Maintain - 03
Execute-16
Administer document storage - 23
Update metadata - 66 <o:p></o:p>

<o:p></o:p>

S_RS_IOBJ: Administrator Workbench - InfoObect <o:p></o:p>

Authorizations
for working with individual InfoObjects and their sub-objects. Until
SAP  BW 3.0A, only general authorization protection was possible with
authorization object
S_RS_ADMWB. General authorization protection for
InfoObjects stillworks as in the past. This authorization object is
checked only if the user is not authorized
to maintain or  display InfoObjects (authorization object:
S_RS_ADMWB-InfoObject, activity: maintain/display).
<o:p></o:p>

If
someone needs to update InfoObjects, but they do not need other
administration functions granted in S_RS_ADMWB, then you can give them
S_RS_IOBJ in lieu of  S_RS_ADMWB. It will provide access to InfoObjects
only.<o:p></o:p>

This
authorization object is checked only if the user is not authorized to
maintain or display InfoObjects (authorization object:
S_RS_ADMWB-InfoObject, activity: maintain/display). You use this
authorization object to restrict how users work with InfoObjects and
their sub-objects.
Until Release 3.0A, only general authorization
protection was possible with authorization object S_RS_ADMWB. General
authorization protection for InfoObjects stillworks as in the past.
Special protection with S_RS_IOBJ is only used if there is no
authorization for S_RS_ADMWB-IOBJ. The following table contains specific
information about the fields in S_RS_IOBJ and how they are
used:<o:p></o:p>

<v:shapetype
o:spt="75" coordsize="21600,21600" filled="f" stroked="f"
id="_x0000_t75" path="m@4@5l@4@11@9@11@9@5xe"
o:preferrelative="t"><v:stroke
joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if
lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1
0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f
eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600
pixelWidth"></v:f><v:f eqn="prod @3 21600
pixelHeight"></v:f><v:f eqn="sum @0 0
1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f
eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600
0"></v:f><v:f eqn="prod @7 21600
pixelHeight"></v:f><v:f eqn="sum @10 21600
0"></v:f></v:formulas><v:path o:extrusionok="f"
o:connecttype="rect" gradientshapeok="t"></v:path><o:lock
v:ext="edit"
aspectratio="t"></o:lock></v:shapetype><v:shape
id="_x0000_i1025" type="#_x0000_t75" alt="bw_auth_obj_1" style="WIDTH:
308.25pt; HEIGHT: 187.5pt"><v:imagedata
o:href="http://www.sapsecurityonline.com/bw_security/bw_security_authorization_objects_clip_image002.gif"

src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image001.gif"></v:imagedata></v:shape><o:p></o:p>

<o:p></o:p>

S_RS_ISOUR: Administrator Workbench - InfoSource – transaction data <o:p></o:p>

Authorizations
for working with transaction data InfoSources and their sub-objects.
You can use this authorization object to restrict the handling of
InfoSources with flexible updating and their sub-objects.
<o:p></o:p>

You
have an administrator who defines what data needs to be extracted from
what source systems. This object protects access to the source systems
and managing the transfer rules. <o:p></o:p>

You
can use this authorization object to restrict the handling of
InfoSources with flexible updating, and their sub-objects. It is
primarily used to protect transaction data. This object will be checked
with creating new InfoSources and when maintaining the InfoSource and
drilling down to monitor the data brought in from source
systems.<o:p></o:p>

<v:shape
id="_x0000_i1026" type="#_x0000_t75" alt="bw_auth_obj_2" style="WIDTH:
308.25pt; HEIGHT: 111.75pt"><v:imagedata
o:href="http://www.sapsecurityonline.com/bw_security/bw_security_authorization_objects_clip_image004.gif"

src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image002.gif"></v:imagedata></v:shape>
<v:shape
id="_x0000_i1027" type="#_x0000_t75" alt="bw_auth_obj_3" style="WIDTH:
308.25pt; HEIGHT: 143.25pt"><v:imagedata
o:href="http://www.sapsecurityonline.com/bw_security/bw_security_authorization_objects_clip_image006.gif"

src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image003.gif"></v:imagedata></v:shape>    
<o:p></o:p>

<o:p></o:p>

S_RS_ISRCM: Administrator Workbench - InfoSource - master data <o:p></o:p>

Authorizations
for working with master data InfoSources and their sub-objects. With
this authorization object you can restrict handling of InfoSources with
direct updating (for master data) or with their sub-objects
<o:p></o:p>

You
have an administrator who defines what master data needs to be
extracted from specific source systems. This object protects access to
the source systems and managing the transfer rules.
<o:p></o:p>

With
this authorization object, you can restrict handling of InfoSources
with direct updating (for master data) or with their sub-objects.

<o:p></o:p>

<v:shape
id="_x0000_i1028" type="#_x0000_t75" alt="bw_auth_obj_4" style="WIDTH:
308.25pt; HEIGHT: 253.5pt"><v:imagedata
o:href="http://www.sapsecurityonline.com/bw_security/bw_security_authorization_objects_clip_image008.gif"

src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image004.gif"></v:imagedata></v:shape><o:p></o:p>

For a complete list of objects, go to transaction code SU03 and drill down to the authorization object class Business Information Warehouse.
You
will notice some objects we dealt with in reporting that are also used
here: S_RS_HIER, S_RS_ICUBE, S_RS_COMP, and S_RS_COMP1. If your company
is storing data in ODS objects, you will need to use S_RS_ODSO.
Note: Some companies use ODS objects to hold large amounts of
detailed data. An ODS object is another storage location for data,
similar in some respects to an InfoCube. If you are using ODS
objects, you will use object S_RS_ODSO in the same way that you
use object S_RS_ICUBE. <o:p></o:p>

<o:p></o:p>

S_RS_ICUBE: InfoArea, InfoCube, InfoCube sub-object <o:p></o:p>

Authorizations
for working with InfoCubes and their sub-objects. For example,
protecting users who can define the InfoCube, applying update rules, and
looking at the data in the InfoCube. <o:p></o:p>

Your
SAP BW administrator creates  InfoCubes. You have a user who  needs
access to the data in one of the new InfoCubes. Although the
authorization values will be different, both the administrator and the
user require access to  S_RS_ICUBE. This object protects all the
essentials for working with InfoCubes. <o:p></o:p>

Authorization
object S_RS_ICUBE also protects the InfoArea and the InfoCube. The
difference between objects S_RS_ICUBE and S_RS_COMP is that
authorization object S_RS_ICUBE is more focused on the data in the
InfoCube, while S_RS_COMP is more focused on query execution.
Authorization object S_RS_ICUBE is required for reporting even if you
have implemented object S_RS_COMP, because it grants access to actually
display the data held in the InfoCube. The following table lists the
fields in authorization object S_RS_ICUBE and how they are used.
<o:p></o:p>

<v:shape
id="_x0000_i1029" type="#_x0000_t75" alt="bw_auth_obj_5" style="WIDTH:
308.25pt; HEIGHT: 123pt"><v:imagedata
o:href="http://www.sapsecurityonline.com/bw_security/bw_security_authorization_objects_clip_image010.gif"

src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image005.gif"></v:imagedata></v:shape>
<v:shape
id="_x0000_i1030" type="#_x0000_t75" alt="bw_auth_obj_6" style="WIDTH:
308.25pt; HEIGHT: 132pt"><v:imagedata
o:href="http://www.sapsecurityonline.com/bw_security/bw_security_authorization_objects_clip_image012.gif"

src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image006.gif"></v:imagedata></v:shape><o:p></o:p>

S_RS_ODSO:  Authorizations for working with ODS objects and their sub-objects. <o:p></o:p>

In
addition to InfoCubes, the SAP BW administrator may create ODS objects
to handle large amounts of transaction data. The user again needs access
to the data in some of the ODS objects. S_RS_ODSO is to ODS objects as
S_RS_ICUBE is to InfoCubes. <o:p></o:p>

<o:p></o:p>

S_RS_ISET : Authorizations for working with InfoSets <o:p></o:p>

InfoSets are protected by the authorization object S_RS_ISET.
This authorization object protects the InfoSet by the InfoArea.
Additional protection includes the activity and protecting the InfoSet
at definition time as well as access to the data. A reporting user will
need activity 03 with access to look at the data. The following fields
are in S_RS_ISET: <o:p></o:p>

• InfoArea: InfoArea user should access <o:p></o:p>
• InfoSet: InfoSet user should access. <o:p></o:p>
• Activity: For a reporting user, should be display (03). <o:p></o:p>
• Subobject: For a reporting user, should be .DATA.. <o:p></o:p>

The
fields for this object are similar to S_RS_ICUBE and S_RS_ODSO. They
all access by InfoArea, activity (display), and access to the data.
<o:p></o:p>

S_RS_HIER: Authorizations for working with hierarchies
Authorizations
for working with hierarchies. This object is used to determine who can 
create hierarchies, as well as who can run queries that use
hierarchies. <o:p></o:p>

In
order to execute a query that uses a hierarchy, the user also needs
access to S_RS_HIER. This object protects all hierarchies in general.
The user needs activities 03 (display) and 71 (analyze) in order to see
the hierarchy results and execute a query that uses a hierarchy. In the
object, you can further limit the user to specific InfoObjects and
hierarchies. <o:p></o:p>

S_RFC Authorization for GUI activities<o:p></o:p>

Add following RFC_NAMEswith RFC_TYPE ‚FUGR‘ and ACTVT ‚16‘
RRXWS: BW Web Interface
RS_PERS_BOD: Personalization of BexOpen Dialog
RSMENU: Roles and Menus<o:p></o:p>

S_GUI Authorization forGUIactivities. Add the activity 60 (upload)<o:p></o:p>

五、创建自定义的权限对象

Steps to Implement InfoObject Security or field-level security as it is called.

1. Making the InfoObject authorization-relevant.
   This is
   done in InfoObject defination in Bex tab. Your business needs will drive
   which InfoObjects should be relevant for security. Keep in mind this is
   made to make help to run Business better.
2. Next step is to create a custom reporting authorization object.
   There
   is no reporting authorization object provided for InfoObjects. Securing
   of infoobject is done by creating authorization object. This can be
   done using transaction RSSM. Only InfoObjects that have been marked Authorization Relevant can be put in a reporting authorization object.
3. Adding your new authorization object to a role.
   After linking your authorization object to the appropriate InfoCube, you have to manually insert your object into a role.
4. Add a variable to the query.
   The only way the query can restrict data dynamically is through a variable.
5. Finally linking the reporting authorization object to an InfoProvider.
   You
   will impact people currently executing queries for the InfoProvider
   that is now related to your reporting authorization object. This linkage
   forces your reporting authorization object to be checked when ANY query
   tied to the InfoProvider is executed.

Create a Reporting Authorization Object

1. Go to SAP Business Information Warehouse choose Business Explorer >> Authorizations>> Reporting Authorization Objects.
2. Choose Authorization Object >> Create.
   Enter
   a technical name and a description for the reporting authorization
   object. Save your entries. You can only assign those which are
   previously marked authorization relevant.
3. Assign the InfoObject fields to the reporting authorization object:
4. Save your entries

相关连接：

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/39f29890-0201-0010-1197-f0ed3a0d279f

http://www12.sap.com/germany/about/company/revis/pdf/DS_Leitfaden_BW_en.pdf

http://www.sap.com/germany/about/company/revis/pdf/DS_Leitfaden_BW_en.pdf

http://help.sap.com/bp_biv270/documentation/SAP_BW_3.5_Functoin_Detail.pdf

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/1b439590-0201-0010-ea8e-cba686f21f06

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30adcac6-7a55-2a10-9fa9-a61d947f6ec9