POSTS PORTFOLIO SEARCH SHOP
PORTFOLIO
SEARCH
+01 (414) 230 - 5550
Blog

Demystifying SAP BPC Embedded Security (Blog # 4)

By on

October 1, 2017

- Blog

BPC administrator is used to manage task access and data access in the administration console in BPC classic . With BPC embedded, SAP has introduced more layers to the security configuration. This is fully understandable as BPC security must now work in conjunction with BW/NW security architecture. This blog is an attempt to demystify the security setup of BPC embedded for BPC classic users.

Traditionally BPC has two distinct aspects of authorization:

  1. Task Access: What tasks a user can perform (aka “Task Profile” in classic BPC)? Task profile determines if the users can perform administration tasks or post journals or run consolidation steps etc.
  2. Data Access: What data intersections user has access to (aka “Data Access Profile” in classic BPC)? Data Access Profile determines if a user can access a particular company or profit centre. These dimensions should be marked as secured dimension at the model level

To keep the example simple, we assumed that the queries created in BW for the purposes of BPC embedded will not be accessed outside BPC. In other words, the BW queries created for BPC models will not be consumed directly via BW.

Embedded BPC has some peculiarity when it comes to the authorization. Let us try to understand the set up  process.

  1. Prerequisites
  2. Task Level Access: Managed via “Roles” in BW
  3. Data Access:
    1. Analysis Authorization
    2. Environment Authorization
    3. Data Access Profile
  4. Assigning Access:
    1. Assign “Role” directly in BW
    2. Assign “Data Access Profile” in BPC
  5. How does it work?
  6. Links & References

Prerequisites

Complete your environment and model set up in BPC Embedded web administration console and make your dimension authorization relevant in BW.

Task Access

Setting up role

As mentioned in the section above the role, at a high level, acts as a “Task Profile”. Note that this could also provide data access via using the BW authorization but for this example we are not setting up that way.

The role can be create using PFCG TCODE in BW. A typical embedded role will have the following authorisations (refer to security guide for comprehensive list).

  1. RSBPC_ID: Grants the user access to an environment
  2. RSBPC_ENVM: Manage the environment
  3. RSBPC_MODL: Manage Model
  4. RSBPC_BBPF: Manage and use BPF
  5. RSBPC_TEAM: Manage Team
  6. RSBPC_WKSP: Resource Management
  7. RSBPC_USER: Manage Users
  8. RSBPC_DAP: Manage Data Access Profiles
  9. S_RS_AUTH; This points to an analysis authorization object. To run global queries, users must have proper authorization with an authorization object. This will give access to the queries directly from BW to the users. To configure a BPC classic style security, you can ignore this configuration or assign the most restrictive authorization object.

Apart from these BPC specific authorization, you will have to configure BW specific authorization that will provide the users with access to specific info objects, queries, planning function/sequences etc. The BW security administrator will be able to guide you on that.

Data Access

Analysis Authorization

The analysis authorization to the role should be assigned via the S_RS_AUTH authorization object mentioned above. Analysis authorization is used for authorizing users in BW realm.

As part of our configuration we deliberately ignored this configuration to prevent BPC queries from being accessed directly from BW. You should consider this setting only if you want to provide query access via BW (outside BPC).

You can use RSECADMIN to create/maintain analysis authorization

Environment Authorization

The environment authorization defines the data access BPC service will have on the info object. This is not a user specific permission. Think of this as a data access permission given to the BPC service on the BW info object. This permission is granted for each BPC environment.

First use RSECADMIN to create an analysis authorization. In our example, we have given read permission to all members of the secured dimension.

Then assign this authorization to BPC environment via the RSECENVI tcode.

Note that this permission along with the Data Access Profile defined in the next step will only come into effect when the model is assigned to analysis for office workbook.  The workbook should be reopened after assigning the model

Data Access Profile in BPC

We have provided all access to the BPC service account via the previous step. Now, we are ready to provide the user with the data access profile via the BPC Admin Console. This is in line with data access profile assignment in BPC classic.

Assigning Access

Assigning BW Roles

Now assign roles via BW using SU01 TCODE. Assign the role created as part Step 1.

Assigning DAP

Similar to BPC Classic, assign the data access profile to the user or team via the BPC Admin console.

How does it work?

Task Access

The user gets all “Task Access” via the BW Roles. This role determines the task level authorization of the user like

  1. Access to BPC Environment,
  2. Access to BPC Model,
  3. Ability to Perform Administration in BPC etc.

Task Access = 

B = Via the BW Role created as part of step 1

Data Access

The data access to the user comes from three different levels of authorizations. BW Role, Environment Authorization and Data Access profile influences this behaviour.

Given we haven’t assigned any analysis authorization (S_RS_AUTH) in the BW role, the data access is determined via the Environment Authorization and Data Access Profile. This also restricts the users from directly accessing the queries via BW bypassing BPC data access framework.

When the user opens the BPC workbook (with model associated with it), BPC’s environment authorization (Step 2.2) and Data Access Profile (Step 2.3) takes over. The simple formula for determining Data Access would be the following:

Data Access = 

  1. B = Authorization Object assigned to the BW Role via S_RS_AUTH
  2. E = Environment authorization assigned via RSECENVI
  3. D = Data Access Profile assigned via BPC Admin Console

In our example, “B” doesn’t provide any data access. While “E” provides access to all members and “D” restricts the access provided by “E”. In short, the user gets data access to only members defined by “Data Access Profile” via BPC Admin Console.

Links & References

For further detailed read, go through these links.

0