BI--SAP BI的权限管理

最新推荐文章于 2024-04-24 22:51:49 发布

iteye_1503

最新推荐文章于 2024-04-24 22:51:49 发布

阅读量123

点赞数

文章标签： java

一、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.

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.
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

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.

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.

The following table contains specific information about the fields in S_RS_COMP and how they are used.

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.

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.

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.

The following table details the fields in S_RS_COMP1 and how they are used.

S_RS_FOLD Display authorization for folder. This object is new in SAP BW 3.0

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

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

四、SAP BI的管理对应的权限对象权限

S_RS_ADMWB: Administrator Workbench - Objects

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

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.

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:

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

The following list shows possible values for the Activity field.
Maintain - 03
Execute-16
Administer document storage - 23
Update metadata - 66

S_RS_IOBJ: Administrator Workbench - InfoObect

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).

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.

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:

S_RS_ISOUR: Administrator Workbench - InfoSource – transaction data

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.

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.

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.

S_RS_ISRCM: Administrator Workbench - InfoSource - master data

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

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.

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

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.

S_RS_ICUBE: InfoArea, InfoCube, InfoCube sub-object

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.

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.

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.

S_RS_ODSO: Authorizations for working with ODS objects and their sub-objects.

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.

S_RS_ISET : Authorizations for working with InfoSets

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:

InfoArea: InfoArea user should access
InfoSet: InfoSet user should access.
Activity: For a reporting user, should be display (03).
Subobject: For a reporting user, should be .DATA..

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.

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.

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.

S_RFC Authorization for GUI activities

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

S_GUI Authorization forGUIactivities. Add the activity 60 (upload)

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

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