Managing BPC security without using the web-based administration tools

[former_member192799]

The information in this blog applies to SAP Business Planning and Consolidation 10, version for SAP NetWeaver, including the version powered by SAP HANA.

SAP Business Planning and Consolidation 10, version for SAP NetWeaver is complete solution for financial and operational planning as well as consolidations and reporting, through a single application and user interface.

Part of the interface is used for the administration of the product. It is a web-based interface, and it is well designed and intuitive.

There could be however some instances where it would be useful to be able to handle some of the administration tasks from the backend. For example when BPC is used in conjunction with other products, it could be useful to be able to link some administrative tasks across the product, maybe by using some scripts.

This article describes how BPC security is implemented and how some of the tasks that can be done directly in the ABAP server without using the BPC administration tool. Please note that managing security this way is probably NOT supported by SAP. It is also limited in scope, as it describes user assignments to teams and profiles but it does not address the management of the profiles. Those latter tasks should be done with the normal BPC administration tool.

Let’s first take a look at how BPC Security is managed in the BPC Administration console:

BPC Security management is divided into four main topics:

-          User (who I am)

-          Task Profile (what I am allowed to do)

-          Data Access Profile (what data I have access to, and what rights I have over that data)

-          Teams.  The teams don’t play as important a role in BPC security but rather are containers that make security management a lot easier by joining multiple users with similar access needs and linking them as a group to the appropriate profiles.

In this example we have a team named Team 1, which has a data access profile names Data1 and a task profile named Task 1

Data Access Profile for Team 1

Task profile for Team 1

We also have a user: NewUser

NewUser is part of Team1

And has the profile “Primary Admin”. Note that because it is a member of Team 1 it inherits the Task 1 task profile from Team 1.

It also inherits Data 1 data access profile, but does not have one on its own.

No let’s look under the hood…

BPC 10 NetWeaver, in contrast to its predecessors, uses SAP ABAP user accounts, rather than Windows Active Directory  or SAP BusinessObjects CMS accounts. The BPC user accounts are dialog ABAP accounts, and can be created in SU01. But once created, their rights are usually managed using the BPC administration tools.

Having an account in ABAP does not automatically grant any access to BPC. Instead, each BPC environment has an ABAP role associated with it. That ABAP role defines whether or not a user’s account is listed as a user in that environment. It does not grant that user any rights beyond being “known” as a user of that environment. In other words, the user can authenticate but will not gain access to anything at that point.

The role name for each environment is listed in table UJE_USER_AGR (accessed with Transaction code SE16)

Each task profile for a given environment is also associated with an ABAP role. Same thing for each Data Access Profile.

The role name for each Task Profile and each Data Access Profile is listed in table UJE_PROFILE_AGR. (here showing only the roles for the environment BPCC_XX). Note the Data 1 and Task 1 profiles

There is a column in that table that defines whether it’s a Task Profile (TSK) or a Data Access Profile (MBR) (Data Access Profiles were formerly called Member Access Profiles).

The roles for the BPC teams are listed in table UJE_TEAM_AGR. Each Team has two roles associated with it: one that indicates membership to that team, and one for the team lead. The Team Lead role does not replace the basic team role. Instead it gets added as an extra role when applicable.

Now let’s take a look at the user role assignments in SU01

From top to bottom, we have:

-          Two technical POA roles that are necessary for accessing BPC Web. Those are independent ofBPC Security

-          The role associated with Data 1

-          The role associated with PrimaryAdmin task profile

-          The role associated with Task 1

-          The role associated with Team 1

-          And finally the role associated with being a user of BPCC_XX

Notice that even though NewUser has the Data 1 and Task 1 profiles only through Team1, the profiles are applied directly to the user account. One major difference between the BPC administration tool and managing user access in SU01 is that in SU01, adding a user to a team (by applying the appropriate team role) is not enough to grant that user the BPC profiles that are associated with that team.

For example, if you have a team named Team 2,  and the BPC profiles Task 2 and Data 2 are associated with that team in BPC administration, granting a user the roll associated with Team 2 in SU 01 will not automatically grant the roles associated with the Task 2 and Data 2 profiles. Those roles would need to be added separately. But if the user is added to the team in the BPC administration tool, then SU01 will show that the user was granted the roles corresponding to that team as well as the roles matching the respective BPC profiles that are associated with that team.

This is obviously something that must be handled carefully, in order to avoid giving the wrong access.

Now, let’s say that we decide that NewUser should no longer be a Primary Admin. We can either go to BPC administration and use the web interface to remove that profile from the user, or we can go to SU01 and remove ZBPC_SBP000001 from the roles listed for that user

With the result that in BPC administration, NewUser no longer has the PrimaryAdmin profile (but still has Task 1 as we have not removed that role)

Understanding those concepts opens the door to experimenting with managing BPC Security from the back-end and eventually to reducing some of the administrative overhead, for example by scripting some tasks.