SAP-BW/BI Reporting Authorization
SAP-BW/BI Reporting Authorization
The purpose of the document is to provide BI Authorizations details that can help in understanding what security setup are required for SAP BI/BW reporting needs.
The Authorization Concepts are segregated to a number of different categories of users as end users, developers, production support etc… :
High level different Categories:
– Functional Authorizations
– Report Authorizations
– Data Authorizations
To have further explanation to these categories:
– Restrict a user to execute a particular tool or feature within the BW toolset. Different functional authorization will allow different levels of access to display or change data models, queries/reports, monitoring tools & administration activities. Functional roles include. Below are different examples of users who can perform different activities, so will be provided different functional roles.
· Data consumer
· Super User
· Configuration – Display
· Developer – Basic
· Developer – Advanced
· Production Support
· Production Scheduler
· Production Emergency User
– Functional Authorizations are maintained by Roles hence maintained using PFCG
Example for Data Consumer role, a PFCG role can be created with having access to execute BW queries:
Complete objects for RFC_NAME can be maintained as:
BAPI_CUBE*, BAPI_IOBJ*, BAPI_MD*, RFC1, RRMX, RRXWS, RRY1, RSAB, RSAH, RSAN, RSBAPI*, RSBAPI_IOBJ, RSCR*, RSMENU, RSNDI*, RSOB, RS_PERS_BOD, RS_UNIFICATION, RZX0, RZX2, SM02, SMHB, SRFC, SURL, SUSO, SUSW, SU_USER, SYST
Note: If user experience any access issue for accessing any hierarchy data or any other object; the error can be checked just after the auth issue in transaction SU53.
Similar to Query consumer role, other roles are created for having different accesses for different groups as stated above.
– The reporting authorization primarily controls Provider level of security.
– The report authorization is generally organized by functional areas and applicable for end users or power users who are needed to restricted on specific area:
– Different Reporting Roles can be created based on areas like
· Profitability Analysis – COPA
· Account Receivables
· Sales and Distribution
· Account Payable
· Cost Centre Reporting
· Asset Accounting
– Report Authorizations are maintained by Roles hence maintained using PFCG
Example of a reporting role that is created in PFCG which provide access to run BW queries that are created top on GCOPA* providers:
Note: In above example, info providers are created as GCOPA* naming convention and similar will require change / updates as per followed naming conventions. Here reporting components provide access to query components available with these name like 0*, G*, L*, R*, T*. If any query is created with Z* name, user will not be able to access without adding access of Z*.
– The data authorization allows access to the actual data content held within the BW data warehouse. This is called Analysis Authorization.
– The data authorizations allow access based of specific data selections within a specified area of reporting.
– The data authorization includes different objects some as:
· Company Code
· Sales Organization
· Cost Center
– A same analysis profile can provide access for different area or different analysis profiles can be created for each area as one profile for COPA, one for AR and so on.
– Data Authorizations profiles are generated / manually maintained by transaction RSECADMIN
– Profiles can directly be assigned to Users or added in a Role and then Role can be assigned to Users
– Analysis Authorization works on “All-or-Nothing” Rule with exception to display hierarchies and key figure
Scenario: Sufficient Authorizations
Complete selection is subset of authorizations
Query results will be shown
Scenario: Insufficient Authorizations
Complete or part of selection is outside of authorizations
Query results will not be shown at all
– Data access can be restricted by following Authorizations:
· On InfoCube Level
· On Characteristic Level
· On Characteristic Value Level
· On Key Figure Level
· On Hierarchy Node Level
– Prerequisite to apply Data Authorization
· To apply data authorizations restrictions – Authorization Relevant check at Info Object is needed to be marked
· An authorization dimension is a characteristic or navigation attribute
· Authorization of characteristics and navigation attributes can be defined independently of one another
· Authorization Relevant query variable must be included in queries (optional for all * access)
– Manual creation of data authorization is possible from Central maintenance authorizations / transaction RSECADMIN.
· In transaction RSECADMIN, under Authorization – Maintenance
· Provide Authorization name and Create
· Authorization Relevant Objects can be added with Insert option (as in right panel)
· Special Authorization Characteristics can be included with option as below
– Special Authorization Characteristics
· In addition to generic dimensions, an authorization includes special dimensions.
o InfoProvider – 0TCAIPROV
o Validity – 0TCAVALID
o Activity – 0TCAACTVT
· These special characteristics must be included in at least one authorization for a user; otherwise the user is not authorized to execute a query.
· It’s recommended as best practice to include these special characteristics in every authorization for reasons of clarity and analysis security.
· They must not be included in queries.
– Authorizing Characteristic Values
· To provide authorizations to users only to specific sales organizations (e.g., 1101 and 2101) can be maintained as below. Ranges and patterns are also supported in characteristics restrictions.
· Navigational Attributes can be assigned individually. The referencing characteristic (here: 0CUST_SALES) does not need to be authorization-relevant
– Authorizing Hierarchies
· In the same way as with value authorization, authorizations are also granted on hierarchy levels
· Assume hierarchy of sales organization as (these are cities and states in India)
· Hierarchy level authorizations can be granted by ‘Hierarchy Authorizations’ tab under Details
· Access can be granted on different nodes (like here access is required for a node and its sub-nodes and on a leaf of another node). Access will be granted to Two different nodes in this case
· Authorizations can be provided at different levels with maintaining different values as below:
o 0 (Only the selected nodes),
o 1 (Subtree below nodes – Generally Used),
o 2 (Subtree below nodes to level (incl.)),
o 3 (Complete hierarchy),
o 4 (Subtree below nodes to (and including) level (relative))
· As hierarchies can be created as time dependant or version dependant, in such cases Validity Period can also be defined for hierarchies.
o 0 (Name, Version Identical, and Key Date Less Than or Equal to -Recommended)
o 1 (Name and Version Identical)
o 2 (Name Identical)
o 3 (All Hierarchies)
– Assigning Individual Authorizations to users
· In RSECADMIN – Users – Individual Assignment
· Select a user ID and change the assignment
· Then insert individual authorizations to the assigned list
– Assigning Authorizations to Roles
· Authorizations can be assigned to roles, which can then be assigned to users
· Authorization object S_RS_AUTH are used for the assignment of authorizations to roles
· Maintain the authorizations as values for field BIAUTH
There is automatic authorization generation approach available with generating authorizations via maintaining details in different DSO:
Detailed level information for authorization generation is available at help.sap.com