Introduction:

Security is a main concern for many customers, especially when deciding between using import and live models, it also plays an important role when deciding between using SAP Analytics Cloud Enterprise and the Embedded Edition.

In this blog post, I will be demonstrating a security concept that I have implemented for a customer, based on an import model consuming data from SAP SuccessFactors through the standard SAP SuccessFactors connector.

The main aim was to narrow down the need of additional user interference different from any done to SAP SuccessFactors itself, in more simple words, to build a security concept somewhat similar to actually using the SAP Analytics Cloud Embedded Edition on SAP SuccessFactors itself according to the customer’s specific design, but on the Enterprise Edition.

Here is the use case as per the customer’s request:

Security Concept Graphical Representation

As per the customer’s requirement:

The solution itself is very simple and straightforward, the result of the following steps will be that only user creation and deletion tasks will have to be maintained on SAP Analytics Cloud.

Step by Step Guide

Enable Model Data Privacy

This step is a prerequisite to creating a role that provides read access to the model, which can be later on assigned to each user that is required to have access to it, this can be done from the model itself, by accessing the Model Preferences>Access and Privacy>Enable Model Data Privacy

Enable Model Data Privacy

Create a Role

From Main Menu>Security>Roles, click Create a New Role, choose the license type, then choose a suitable template that you can start with, in our scenario I chose “BI Content Viewer” as the template.

In the role itself, click on the Select Model tab, navigate to where the model is located then choose it, note that the model will not be visible unless Model Data Privacy was enabled, choose “Full Access”.

Role Creation

Create a Team

The “HR_ADMINS” Team will be used a container in which any user who is required to have access to all Sectors, Divisions and Departments combinations will be assigned to.

This can be done from the Main Menu>Security>Teams>Create Team

Share the Stories and Models

In order to keep minimal administrative interference, share the top folder containing the stories and models with All Users, in this scenario, it will be the main “HR Folder”

Folder Structure

Select the share icon beside the HR Folder, make sure the “Share existing subfolders and files” option is enabled, in “Add Users or Teams” choose “All Users”, make sure they have “View” Access.

Folder Sharing

Note that the stories and model will be visible for anyone as objects only, until this point, only the model owner can view the data inside.
You can also remove undesired access for specific objects underneath the main folder path.

Enable Dimension Data Access

Data Access can be enabled for a specific dimension either from the model or from the dimension itself.

As per the mentioned scenario, the lowest access level is for the Division heads, hence Data Access needs to be enabled on the ZDIVISION dimension, once Data Access is enabled, a Read column will be visible, where the access can be manually defined for each member, or loaded from the source system.

Load the relevant data to the Read property

The key idea here is to grant access to the specific Sector Head, specific Division Head, and HR_ADMINS Team, to automate this, I used the standard Job Information table, querying the fields below:

Division, Division Head, Sector Head Query

Note that Each member will be retrieved multiple times, as long as the duplicated rows have the same field values it will not be an issue, to ensure this we need to apply a filter on the Employee Status “Active” and the division effectiveEndDate as “9999-12-31” which basically means active as well.

Now, we need to create a calculated dimension that concatenates the Sector Head USERID, Division Head USERID and the HR_TEAM

Read Calculated Dimension

The use of the ISNULL() formula above is to simply avoid having a string that starts or ends with “;” as these will cause a validation issue, another alternative would simple be replacing all empty rows for both Division Head and Sector Head fields with “#”, then simply doing the concatenation.

Calculated Dimension Result

As shown in the screenshot, the “HR_ADMINS” team will always have access to every member.
Now we simply map the Read property to the calculated dimension.

Create the Users and Assign Members to the Team

Now to the final part of this use case, all users that are required to have access to the stories based on the model will have to be created using their SAP SuccessFactors USERID having the role we created, and just like that they automatically have access to the relevant subset of data they are allowed to view.

In case the user was an HR_ADMIN, the USERID will not matter, a user will have to simply be created having the role “ZHR_ECHC_VIEWER” then assigned to the HR_ADMINS team.

To quickly create the users in our scenario, we exported the existing user list from Main Menu>Security>Users>Export to use it as an upload template, filled it out with the new users’ information and uploaded it again.

Users List Template

We can talk about various available methods to integrate the users creation process with other systems, I recommend checking the SAP Analytics Cloud User and Team Provisioning SCIM API Best Practices and Sample Scripts blog post created by Mathew Shaw.

General Notes

• Creating a Validation Story containing a simple table showing the name of Sector and Division heads as properties to the Division dimension would be a useful reference for both the SAC and HR admins, so they can always see who has access to which data guiding them through any changes that should be applied to either SAP Analytics Cloud or SAP SuccessFactors.
• As per this solution, whenever a Sector Head or a Division head change for a certain Division, the change has to be only maintained on SAP SuccessFactors, SAP Analytics Cloud will pick the changes automatically after the next scheduled load for the Read property.

I hope this use case helps you apply your own desired security rules to the import models you have. Theoretically speaking, this concept can be applied for other source systems as well.