SAP Net Weaver BI Security

SAP BI Security Before we go any further into SAP BI Security let us first differentiate the BI Security from R/3 security. In R/3 the Security is mainly focused on Transaction codes, Specific field values and activities done by the users as the motive in R/3 is to get the daily work done as soon and as effective as possible. Whereas in BI the security is focused on data itself as almost all the activities revolve around the data. Specifically the BI Security is focused on InfoAreas, InfoProviders and Queries. SAP BI is focused on what data a user can access. This may be controlled at the field level or at the InfoProvider level. In R/3 the authorization object S_TCODE plays a vital role as it acts as a first level of defense. But in BI as the number of Transaction codes is very few the authorization object S_TCODE has very little role to play in BI security. The basic difference between R/3 and BI is that R/3 is focused on updating the business data whereas BI is focused on displaying and analyzing the data. Authorization Objects There are two types of Authorization objects available in BI, namely Standard Authorization Objects Analysis Authorization Objects Standard Authorization Objects Standard Authorization Objects can be used to protect the access to both reporting as well as Administrative users. Reporting includes Creation of Queries, Execution of Queries, Saving Queries into Favorites folder and Administrative tasks include Data Modeling(Creation of various objects like InfoCubes, Multiproviders,DataStores, DataSources, InfoPackages and DTPs),Data Scheduling and Load monitoring. However the granular security to reporting users can not be achieved through Standard Authorization Objects. The following are the various Standard Authorization Objects which will be needed for the following activities. For Reporting S_RS_COMP S_RS_COMP1 S_RS_MPRO S_RS_FOLD S_RS_ICUBE S_RS_ODSO S_RS_HIER For Administration S_RS_ADMWB S_RS_IOBJ S_RS_ISOUR

S_RS_ISRCM S_RS_ICUBE S_RS_ODSO S_RS_HIER

The following will explain the Standard Authorization Objects in detail. S_RS_COMP Using this authorization object, you can restrict the components that you work with in the Business Explorer query definition. It is very powerful Authorization Object for reporting. The object contains four fields: InfoArea: Determines which InfoAreas a given user is allowed to process. InfoProvider: Determines which InfoProviders a given user is allowed to process. Component type: Determines which components a given user is allowed to process. Calculated key figure (Type = CKF) Restricted key figure (Type = RKF) Template structure (Type = STR) Query (Type =REP) Variable..... (Type = VAR) Name (ID) of a reporting component: Determines which components (according to name) a given user is allowed process. Activity: Determines whether the user is allowed to Create (Activity =01) Change (Activity =02) Display (Activity =03) or Delete (Activity =06) a component. The activities 16 'Execute', and 22 'Save for reuse' are not currently checked by the query definition. 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' Using this we can restrict the power users to create queries only with the naming convention mentioned in this Authorization Object. It can also be used to restrict access to create queries only on the InfoProviders which lie under the InfoAreas mentioned here. S_RS_COMP1 With this authorization object, you can restrict query component authorization with regards to the owner. This authorization object is checked in conjunction with the authorization object S_RS_COMP. The object contains four fields: Name (ID) of a reporting component: determines which components (according to name) are allowed to be edited by the user Type of reporting component: determines which component types are allowed to be edited by the user Calculated key figure (Type = CKF) Restricted key figure (Type = RKF) Structure (Type = STR) Query (Type = REP) Variable (Type = VAR) Reporting component owner: determines whose components are allowed to be edited by the user Activity: determines whether the user is allowed to change a component (Activity = 02) is allowed to display a component (Activity = 03) is allowed to delete a component (Activity = 06) S_RS_ADMWB Using this authorization object, we can restrict the work done with certain objects in the Data Warehousing Workbench It restricts access to work with various objects within Admin work bench. It is checked throughout the execution of RSA1.The objects in Administration workbench include InfoObjects,InfoAreas,Source Systems, Application Components, InfoPackages, Meta data, Master data etc., The object contains two fields: Data Warehousing Workbench Object:

You specify the Data Warehousing Workbench object that a user can edit. The following objects exist: SourceSys Source system InfoObject InfoObject Monitor Monitor ApplComp Application component InfoArea InfoArea Workbench Data Warehousing Workbench Settings Settings MetaData Metadata InfoPackag InfoPackage and InfoPackage group RA_Setting Reporting Agent setting RA_Package Reporting Agent package DOC_META Documents for metadata DOC_MAST Documents for master data DOC_HIER Documents for hierarchies DOC_TRAN Documents for transaction data DOC_ADMIN Administration of document storage CONT_ADMIN Administration of Content systems CONT_ACT Installation of Business Content BR_SETTING Broadcast settings (not including your own settings, which have one of the following distribution types: Broadcast E-Mail, Broadcast to Portal, Broadcast to Printer) USE_DND Drag and drop to InfoAreas and application components CNG_RUN Attribute change run REMOD_RULE Modeling Rule "Modeling Rule" for the remodeling tool IMG_BI BI-relevant activities in the IMG (Customizing) OLAP_CACHE OLAP cache objects BIA_ZA BI accelerator monitor checks and activities Activity: Specifies whether you are permitted to display or maintain a sub object Display Source System (Activity = 03) Display InfoObject (Activity = 03) Display Monitor (Activity = 03) Display Reporting Agent Setting (Activity=03) Display Reporting Agent Package (Activity=03)

Display Documents for Metadata (Activity=03) Display Documents for Master Data (Activity=03) Display Documents for Hierarchies (Activity=03) Display Documents for Transaction Data (Activity=03) Maintain Source System (Activity = 23) Maintain Application Component (Activity = 23) Maintain InfoArea (Activity = 23) Maintain InfoObject (Activity = 23) Maintain Settings (Activity = 23) Maintain InfoPackage (Group) (Activity = 23) Maintain Reporting Agent Setting (Activity=23) Maintain Reporting Agent Package (Activity=23) Maintain Documents for Metadata (Activity=23) Display Documents for Metadata (Activity=03) Maintain Documents for Master Data (Activity=23) Display Documents for Master Data (Activity=03) Maintain Documents for Hierarchies (Activity=23) Display Documents for Hierarchies (Activity=03) Maintain Documents for Transaction Data (Activity=23) Display Documents for Transaction Data (Activity=03) Manage Document Storage (Activity=23) Manage Content Systems (For example, Switch to Content System) (Activity=23) Install Business Content (Activity = 63) Caution: The "Install Business Content" activity is not active in the current release. (No authorization check is performed.) Display Broadcast Settings (Activity=03) Execute Broadcast Settings (Activity=16) Maintain Broadcast Settings (Activity=23) Execute Data Warehousing Workbench (Activity = 16) Update Metadata (Activity = 66) Drag and drop to InfoAreas and Application Components in the DW Workbench (Activity = 16) Start Attribute Change Run (Activity = 16)

Display OLAP Cache Objects (Activity = 03) Delete OLAP Cache Objects (Activity = 06) Display BI Accelerator Monitor Check Results (Activity = 03) Execute BI Accelerator Monitor Actions (Activity = 16) S_RS_IOBJ Definition You use this authorization object to restrict how users work with InfoObjects and their subobjects. 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). It restricts which individual InfoObject a user can work with as this restriction is not maintained in S_RS_ADMWB. The object has four fields: InfoObjectCatalog: This is where you specify the key of the InfoObject catalog that a user is authorized to work with. InfoObject: A user is authorized to work with the InfoObjects that you specify here. Sub-object of the InfoObject: You use the sub-object to specify the parts of the InfoObject that a user is permitted to work with. There are the following sub-objects: Definition UpdateRule Activity: Determines whether a user is allowed to display, delete, maintain, or update a sub-object. Display InfoObject-Definition (Activity = 03) Maintain InfoObject-Definition (Activity = 23) Display InfoObject-Update Rules (Activity = 03) Maintain InfoObject-Update Rules (Activity = 23) S_RS_IOBC Working with the InfoObject catalog can be restricted with this authorization object. The object includes three fields: InfoArea: Here you can specify the key for the InfoArea for which a user can edit the InfoObject catalog. InfoObject catalog: Here you can specify the key for the InfoObject catalog that a user can edit. Activity: Determines whether you can display or maintain an InfoObject catalog. Display InfoObject Catalog (Activity = 03)

Maintain InfoObject Catalog (Activity = 23) This authorization object is only checked if the user has neither general maintenance authorization nor display authorization for InfoObjects (Authorization Object: S_RS_ADMWB InfoObject, Activity: Maintain/Display). S_RS_ICUBE Using this authorization object you can restrict working with InfoCubes or their subobjects. It can be used to restrict access to what a user can do with an InfoCube.For example, he can define, modify an InfoCube or apply update rules to it or just display the data in it. It is necessary for both reporting and administrative users. The object contains four fields: InfoArea: You enter the key of the InfoArea for which a user is allowed to edit InfoCubes. InfoCube: The InfoCubes that you enter here can be edited by a user. Subobject for InfoCube: Using the subobject you specify the part of the InfoCube that the user is to edit. The following subobjects exist: Definition - Definition UpdateRule - Update rules Aggregate - Aggregate Data - Data ExportISrc - Export DataSource Chavlrel - Characteristic relations (planning relevant) Dataslice - Data slices (planning relevant) Activity: Determines whether you can display, delete, maintain or update a subobject. Display InfoCube definition (activity = 03) Display InfoCube update rules (activity = 03 ) Maintain InfoCube data (Administrate InfoCube) (activity = 23) Display InfoCube aggregate (activity = 03) Delete InfoCube data (activity = 06) Maintain InfoCube definition(activity = 23) Maintain InfoCube update rules (activity = 23) Maintain InfoCube aggregate (activity = 23) Maintain InfoCube export DataSource (activity = 23) Update InfoCube aggregate (activity = 66) Display InfoCube characteristic relationships (activity = 03) Maintain InfoCube characteristic relationships (activity = 23)

Activate InfoCube characteristic relationships (activity = 63) Display InfoCube data slices (activity = 03) Maintain InfoCube data slices (activity = 23) Activate InfoCube data slices (activity = 63) S_RS_ODSO Using this authorization object, you can restrict working with the Data Store objects or their subobjects. It is used to restrict access to what a user can do with an ODS.He can create, modify or apply update rules or just display the data in it.ODS is similar to InfoCubes.But ODS stores large amount of transactional data with detailed information. This authorization is necessary for both reporting and administrative users. The object contains four fields: InfoArea: You enter the key for the InfoArea for which the user is permitted to edit DataStore objects. DataStore Object:The user is permitted to edit the DataStore objects that you specify here. Subobject for DataStore Object:You use this subobject to specify the part of a DataStore object that the user is permitted to edit. The following subobjects exist: Definition - Definition UpdateRule - Update Rule Data - Data ExportISrc - Export DataSource Config - Configuration of runtime parameters Activity: Specifies whether you are permitted to display, delete, or maintain a subobject. Display DataStore object definition (activity = 03) Display update rules for DataStore object (activity = 03) Maintain DataStore object data (Manage DataStore) (activity = 23) Maintain DataStore object definition (activity = 23) Maintain update rules for DataStore object (activity = 23) Maintain DataStore object export DataSource (activity = 23) Maintain runtime parameters of DataStore object (activity = 23) S_RS_MPRO With this authorization object you can restrict working with MultiProviders or their subobjects.

It is checked while defining the MultiProviders and Viewing the data from the underlying InfoProviders The object includes four fields: InfoArea: Here you specify the key for the InfoArea, for which a user is allowed to edit the MultiProvider MultiProvider: The MultiProviders that you specify here are allowed to be edited by a user. Subobject for the Multiprovider: With this subobject you specify the part of the MutliProvider that the user is allowed to edit. There are the following subobjects: Definition Definition ExportDS Export-DataSource Data Data Activity: determines whether you are allowed to display, delete, maintain, or update a subobject. Display MultiProvider definition (Activity = 03) Maintain MultiProvider definition (Activity = 23) Maintain MultiProvider Export-DataSource (Activity = 23) Display MultiProvider Data (Activity =03) S_RS_HIER Using this authorization object you can restrict the working with hierarchies in the Data Warehousing Workbench. This object is used to determine who can create hierarchies, as well as who can run queries that use hierarchies. A reporting user will require access to 03(display) and 71(analyze) activities in order to view the results and execute the queries based on a hierarchy. The object contains four fields: InfoObject: You enter the key of the InfoObject here for which a user is allowed to edit hierarchies. Hierarchy name: Enter the name of the hierarchies that a user is allowed to edit. Hierarchy version: Enter to which version of the hierarchy the authorization refers here. Activity: Determines whether the user is allowed to Display (activity = 03) or Maintain (Activity = 23) a hierarchy or if he or she is allowed to display data along the hierarchy (activity = 71). Example If you want a user to maintain all hierarchies for the InfoObject 0COSTCENTER, assign him or her the following authorizations:

InfoObject: 0COSTCENTER Hierarchy Name: * Activity: 23 S_RS_ISOUR You can use this authorization object to restrict the handling of InfoSources with flexible updating (transactional data) and their sub objects. 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. 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. The authorization object contains four fields: Application component: Enter the application component key here for which a user is allowed to edit InfoSources. InfoSource: Enter the InfoSources with flexibleupdating the user is allowed to edit here. Subobject for InfoSource: You use the subobject to specify the part of the InfoSource that the user is allowed to edit. The following subobjects exist: Definition Definition CommStruc Communication structure TrnsfrRule Transfer rules Data Data InfoPackag InfoPackage MetaData Metadata Activity: Determines whether you are allowed to display, maintain, request or update a sub object Display InfoSource definition (Activity = 03) Display InfoSource communication structure (Activity = 03) Display InfoSource transfer rules (Activity = 03) Display InfoSource data (Activity = 03) Maintain InfoSource definition (Activity = 23) Maintain InfoSource communication structure, (Activity = 23) Maintain InfoSource transfer rules (Activity = 23) Maintain InfoSource InfoPackage (Activity = 23) Maintain InfoSource data (Activity = 23) Delete InfoSource data (Activity = 06)

Request InfoSource data (Activity = 49) The display and maintenance of the InfoSource data is checked in the PSA tree and in the Monitor. Example If you want to allow a user to maintain, but not request, the master data for all InfoSources delivered with the application component CO-PA, assign him or her the following authorizations: Application component: CO-PA InfoSource: 0* Subobject: * Activity: 23 S_RS_ISRCM With this authorization object you can restrict handling of InfoSources with direct updating (for master data) or with their subobjects. The object contains four fields: Application components: Here you enter the application component key for which a user is allowed to edit master data InfoSources. InfoSource: A user is allowed to edit the master data InfoSources you specify here. Subobject for the InfoSource: You can use the subobject to specify the part of the InfoSource the user is allowed to edit. The following subobjects are available: TrnsfrRule Transfer rules Data Data InfoPackag InfoPackage MetaData Metadata Activity: Determines whether you are allowed to display, maintain, request or update a subobject: Display InfoSource transfer rules (Activity = 03) Display InfoSource data (Activity = 03) Maintain InfoSource transfer rules (Activity = 23) Maintain InfoSource InfoPackage (Activity = 23) Maintain InfoSource data (Activity = 23) Delete InfoSource data (Activity = 06) Request InfoSource data (Activity = 49) Display and maintenance of InfoSource data is checked in the PSA tree and in the Monitor.

S_RS_ISET You can restrict working with InfoSets with this authorization object. It is checked while defining an InfoSet and accessing the data from it.InfoSets can be restricted by InfoArea level. The object contains four fields: InfoArea: Enter the key of the InfoArea for which a user may edit Infosets here. InfoSet: Enter the name of the Infoset here. Activity: Define if you may display, delete, or maintain the InfoSet. Display the InfoSet object definition (Activity = 03) Maintain the InfoSet object definition (create, delete, change) (Activity = 23) Subobject for InfoSet: With the subobject you specify the part of the InfoSet that is edited by the user. There are the following subobjects: Definition: Definition Data: Data Authorization Object required for securing InfoArea view in BEx window S_RS_FOLD is used to deactivate the general view of InfoArea folder in the BEx open dialog window. Then only the favorites and roles appear in the BEx open dialog for queries. The view of the InfoAreas is hidden. The object contains a field: SUP_FOLDER: Hide the file view if the field is set to 'True' ('X'). If both 'True' and 'False' is selected ('All Values'), the value 'False' is valid, meaning that the 'InfoAreas' file is not hidden. Authorization Objects required to save the Work books into Favorites Folder S_GUI used for GUI activities. The field Activity must be set to 60 S_BDS_DS used for Document Set. The field Activity must be set to 03 and 30 and the field Class Type to OT. Authorization Objects required to save Workbooks into Role Folder S_USER_AGR for working with roles. The field Activity should be set to 01, 02 and 06 and the field Role Name should be set to the name of the role which is created for saving workbooks. S_USER_TCD.The field Transaction Code should be set to RRMX. Authorization Objects required to maintain the Analysis Authorization Object in Roles S_RS_AUTH BI Analysis Authorizations in Role is used to include the Analysis Authorization Objects into Roles. It contains an Organizational field called BIAUTH which should be maintained with the Analysis Authorization Objects which we want to give access to through this role.

Authorization Object required to work with RSECADMIN transaction code S_RSEC Authorization Object is used to restrict the activities that can be done through RSECADMIN t-code. We can either maintain Analysis Authorization Objects or Assign the Authorization to users or Check the error logs. To do all these we need to have access to S_RSEC. Types of Users and the Authorizations needed There are three types of users in SAP BI, depending on what kind of work they do. Reporting or End Users Power Users/Lead Power Users Administrative Users Reporting Users Reporting users are the ones who execute queries in the BEx analyzer and analyze it. They can not create or modify any queries. Authorizations needed for a Reporting user. S_RS_COMP S_RS_COMP1 S_RS_ICUBE or S_RS_ODSO S_RS_FOLD Power Users Power Users can create queries and save it in the favorites folder. They can not save the queries into a Role for the others usage. Authorizations needed for a Power User. S_RS_COMP S_RS_COMP1 S_RS_ICUBE or S_RS_ODSO S_RS_FOLD S_GUI S_BDS_DS Lead Power Users Lead Power users are empowered to save the queries into a Role. He can modify the queries as and when requirements change. In additional users can create and modify hierarchies on different InfoObjects. Authorizations needed for a Lead Power User. S_RS_COMP S_RS_COMP1 S_RS_ICUBE or S_RS_ODSO S_RS_FOLD

S_RS_HIER S_GUI S_USER_AGR S_USER_TCD

Administrative Users Administrative Users are the ones who develop new BI objects such as InfoCubes, DataStores, InfoPackages, and MultiProviders. They also schedule data loads, create transformations and update rules between the source and target, and monitor the performance. S_RS_ADMWB S_RS_IOBJ S_RS_ICUBE S_RS_ODSO S_RS_MPRO S_RS_ISET S_RS_ISOUR S_RS_ISRCM

Analysis Authorization Objects Using Standard Authorization Objects has got certain limitations. It can not provide security to different reporting scenarios of the business. So to provide the further granular security we need to create our own customized Authorization Objects called Analysis Authorization Objects. Until SAP BW 3.x it was called as Reporting Authorization Objects. Since Reporting Authorization Objects concept was based on Standard Authorization Objects it had many limitations which were rectified in Analysis Authorization Objects as they are not based on Standard Authorization Objects concept. Using Analysis Authorization Objects, the access can be restricted On InfoCube Level On Characteristic Level On Characteristic Value Level On Key Figure Level On Hierarchy Node Level

The following are the steps needed to create and maintain an Analysis Authorization Object Authorization-Relevant Characteristics defined using T-code RSD1 Authorization-Relevant Attributes(Navigational) defined using T-code RSD1 Analysis Authorization Object created using T-code RSECADMIN

InfoObjects,Attributes,InfoCubes and Hierarchy nodes are authorized with recommended values Assignment of the Authorization Objects to the users directly in RSECADMIN or through roles using PFCG

The following examples will explain the different scenarios for which Analysis Authorization Objects are created Suppose if we want to secure the data related to a particular plant, then we have to create an Analysis Authorization Object for 0Plant InfoObject using RSECADMIN. Before creating an Analysis Authorization Object we need to make the corresponding InfoObject as Auth-Relevant using the T-code RSD1.In our case its 0Plant InfoObject. Any Analysis Authorization Object will contain four mandatory fields namely, 0PLANT (InfoObject) 0TCAACTVT 0TCAIPROV 0TCAVALID 0PRODORDER__0PLANT (Attribute)-Optional In the above example, suppose if we want to create an authorization to give access only to the plants of Australia, we have to mention the Plant values of Australia. We can either give the individual values or the range of values. If any Attributes of the InfoObject, here 0PRODORDER__0PLANT, are to be secured, then we can give the possible values the user can have access to. Third Field (0TCAACTVT) in the Analysis Authorization Object represents the activities. Here we can restrict the users access to display or Analyze. 0TCAIPROV field represents the Info providers for which we would like to apply this Security. We can give a single InfoCube name or the List of InfoCubes. 0TCAVALID field represents the Validity of this Authorization Object. If we mention a validity period here, then irrespective of whether the role is active or not the user will have access as per this authorization object. 1) Authorization for Australian Plant ZPLANTAU 0PLANT 0TCAACTVT 0TCAIPROV 0TCAVALID 0PRODORDER__0PLANT 015-016, 0569-0571 03(Display) ZCCA1COPY, ZILUDIC, ZMPSA_MD 01-01-2008 to 01-06-2008 or * *

The above Analysis Authorization Object will now give access only to the data related to the plants of 015-016, 0569-0571 in the above mentioned InfoCubes. As per the new BI model, if an InfoObject is marked as Authorization Relevant, then all the InfoCubes in which the InfoObject resides will be checked for Authorization. So in order to

bye-pass the check for certain InfoCubes, we need to create an Analysis Authorization object with * access and mention the InfoCubes name in the 0TCAIPROV field. Now by assigning this Analysis Auth Object to a user, the authorization checks for the mentioned InfoCubes can be avoided. 2) Authorization for bye-passing the check for certain InfoCubes _0PLANT 0PLANT 0PRODORDER__0PLANT 0TCAACTVT 0TCAIPROV 0TCAVALID * * 03(Display) ZCCA1COPY, ZILUDIC, ZMPSA_MD *

Now the user will not be checked for authorization in ZCCA1COPY, ZILUDIC, ZMPSA_MD as he has full access to those InfoCubes. 3) Authorization for NOSEE ZEMPSENSNOSE In case if we dont want some InfoObjects to be seen by certain users, then we can create an Auth object with: access. It will only display the aggregate values and not the detailed information. In the following example, we can see that the Employee Sensitive data has been protected by: access 0EMPLOYEE__0EMPLSGROUP * 0EMPLSGROUP * 0TCAACTVT 03 0TCAIPROV ZCORPFUNC, ZEDUCAT, ZHRACFR40 0TCAVALID * ZAPPPOSN__0EMPLSGROUP * ZEMPSENS : ZEMPSENS__0COUNTRY_ID : ZEMPSENS__0SALARYLV : ZPSTNSENS :

4) Authorization for SEE ZEMPSENSALL However some users will be requiring to see the above mentioned Employee Sensitive data. To give them the access we need to create an Authorization Object with * access. 0EMPLOYEE__0EMPLSGROUP 0EMPLSGROUP 0TCAACTVT * * 03

0TCAIPROV 0TCAVALID ZAPPPOSN__0EMPLSGROUP ZEMPSENS ZEMPSENS__0COUNTRY_ID ZEMPSENS__0SALARYLV ZPSTNSENS

ZCORPFUNC, ZEDUCAT, ZHRACFR40 * * * * * *

5) Authorization for a particular value of Key Figures ZBILLINGR1 To restrict access to a particular value of Key Figures, we can create an Authorization Object as below 0TCAACTVT 03 0TCAIPROV ZBILLING, ZMCBILLPR 0TCAKYFNM ZCONDZP120000000000000000000 to ZCONDZP09999999999999999999999 0TCAVALID * As a result the above Authorization object gives access only to display the Key figures of above format in the InfoCubes ZBILLING, ZMCBILLPR. In general, Key Figures are security Relevant, so we need to make sure that a general Key Figure Analysis Authorization Object is created to bye-pass the authorization check for certain InfoCubes for which we dont want to have any Security on Key Figures. Attribute Level Security: The access to InfoCubes can be restricted through attributes as well. Only the navigational attributes can be made Security Relevant. If any navigational attribute is made security relevant then all the InfoCubes will be checked for the proper authorization. Hence we need to make sure that the Security Relevant Navigational attributes are properly authorized through Analysis Authorization Objects so that the queries can be executed without any authorization errors. Display attributes cannot be used to build Security. So if we need to create security on an attribute, we should convert it into a navigational attribute using RSD1.

Types of Roles in SAP BI Casual Roles Power User Roles Lead Power User Roles Administrative User Roles RL Roles used to save queries

Transaction Codes used in SAP BI Security RSECADMIN Used to create and maintain Analysis Authorization Objects in SAP BI.It can also be used to assign the authorization objects to the users and trace the authorization checks during the execution of Queries. 1) RSECADMIN window

2) RSECADMIN -Maintenance of Analysis Authorization Objects

3) RSECADMIN-Different fields in an Analysis Authorization Object

4) Maintenance of field values for OPLANT

5) Maintenance of field values for 0TCAIPROV

6) Maintenance of field values for 0TCAACTVT

7) RSECDMIN-Assignment of Analysis Authorization Objects to Users

8) Enter the Users ID to whom the Analysis Authorization Object needs to be assigned

9) Enter the name of the Analysis authorization Object in the Name filed and enter insert.

10) RSECADMIN Trace-Click on Error Logs

11) Enter the User ID of the User,the start and end date. Select Configure Log Recording

12) Now whenever the mentioned user executes a query in RRMX, the authorization checks will be captured and we can display them by trace.

RSDI Used to create and maintain the Characteristic and Key Figure InfoObjects.From security perspective, it is used to make an InfoObject or Navigational Attribute as Authorization Relevant. 1) Enter the name of the InfoObject which needs to maintained

2) Click on Business Explorer tab and check the Authorization Relevant box if the InfoObject needs to secured

RSA1 It is an Administrative transaction code. Used by Administrative users to BI Objects like such as InfoCubes, DataStores, InfoSources, InfoPackages etc. It is also used to create transformations, update rules and DTPs between the source and target systems. The following is the RSA1 window showing the different objects of BI such as InfoCubes, DataStores, InfoSources, DataSources etc,

RRMX It is used to launch BEx analyzer window wherein the reporting users will execute the queries and the power users will create the queries 1) BEx analyzer showing the different queries available for the user under different Info Areas. Double click on the query you would like to execute.

2) The following query is the window appears after executing a query for displaying the Authorization relevant Info objects in an InfoProvider

3) Enter the InfoProvider name for which the Authorization relevant InfoObjects need to be displayed. Click on execute.

4) The following is the result window of the query showing the Authorization relevant InfoObjects in the InfoCube ZILUDIC

For further reference: SAP Business Intelligence-SAP PRESS http://sapsecuityonline.com/ http://help.sap.com/