With SAP Identity Provisioning Service (IPS), SAP offers an abstraction layer for connecting cloud systems with a uniform, standardized SCIM API interface. This allows identity management systems such as SAP IdM, One Identity or Okta to be conveniently connected to SAP Analytics Cloud (SAC) without customizing in order to automate user management.
Although the initial connection works easily, there are some SAC-specific challenges that need to be addressed in this context. We summarize the most important aspects and explain suitable solutions.
Challenge 1: No authorization management via roles
SAC has several entities that are important for user management:
Roles can be used to define technical authorizations, teams can be used to manage visibility of stories and more. However, the SCIM interface only offers two endpoints:
- /Users -> Users
- /Groups -> Teams
It is not possible to manage role assignments via the API.
As a best practice approach, SAP recommends to avoid direct role assignments and to inherit them to users via teams.
Thus, it is sufficient to map role assignments via teams and assign them to users via SCIM API.
Challenge 2: 404 bug with team assignments
There is a known bug in the SCIM API of SAP Analytics Cloud that leads to a 404 error when a team assignment is made. The bug is described in SAP Note 2857395.
The bug occurs when generating IDs for teams via the web UI on the system. This means that the teams cannot be addressed via SCIM. It is easy to check if the bug is also present on your system.
Execute the /Groups API and load the list of all teams
Select a random team and read it one by one
If a 404 error occurs now, the bug is present on your system.
SAP recommends several approaches to fix this problem. We advise the “cleanest” option: deleting and recreating all teams that were created via the UI. In doing so, all assignments (stories, users, roles, etc.) must be reassigned. Even though migration is the more time-consuming solution, we have had the best experience with it and recommend this option.
New creation via Postman
Now the team is also accessible via the SCIM-API.
Since new teams are now created through the SCIM API rather than the UI, the business department will need either a script to create teams or training for Postman. Another option is to design a workflow for creating teams through the identity management tool.
Challenge 3: Deleting role assignments during team assignment
When assigning and deassigning a team, the list of assigned roles must also be included. If this field is empty in the SCIM request, all role assignments in the team will be deleted.
Here is a team with an admin role (PROFILE:sap.epm.Admin).
Now we add a user (D425) to this team without explicitly adding all role assignments.
All role assignments in the team have disappeared.
The recommendation is to always include the list of assigned roles with the SCIM request.
However, this implies that the IdM needs to know this information (Which role is in which team?). The role assignments for teams are managed in IdM and described from there via SCIM.
Since a workflow may already exist for creating teams, this process can also be extended with the management of team role assignments in IdM.
Challenge 4: Personal space and ownership when deleting
In SAP Analytics Cloud, there is an option to be an owner of stories or to build stories in personal space. When deleting, these elements must be optionally transferred to another user, otherwise they are gone.
When deleting via the UI, you are explicitly asked what to do with this data.
When deleting via the API, this option does not exist.
Unfortunately, there is no technical solution to this challenge. However, there are two different options for a workaround:
Deactivate instead of delete
Deleting the user manually only via the system administrator. In this case, when deleting a user in IdM, instead of deprovisioning, an approval or an email is sent to the system owner. The system administrator deletes the user and decides what to do with the data.
Challenge 5: (De)activating users
In SAP Analytics Cloud, it is not possible to activate or deactivate a user via the UI. It is also not possible to see what status a user has.
The SCIM API provides the attribute “active” which reflects the user status.
This attribute can be used to activate and deactivate users. A deactivated user can still log in, but gets an error message and cannot retrieve any data. The status of the user can now at least be tracked and/or controlled via the IdM.
Challenge 6: UserID constraint for email mapping in SSO
If a separate identity provider is selected for Single Sign-On (SSO) and “email” is selected as the mapping attribute, a special mechanism of SAP Analytics Cloud takes effect during user creation. Internally, all userNames are overwritten with email, but in the list of users the domain is truncated for display. When creating new users with userID != email, an error message now appears.
Existing users can still be activated, deactivated and deleted, but a master data change like first or last name causes the same error.
There are two possible solutions for this case:
The userID is also the prefix of the email address (userID=MAXMUSTERMANN, email@example.com). For this, it is necessary to write the complete email address in both userName and email. In turn, SAP Analytics Cloud automatically extracts the userID from the email.
userID should not be identical to the prefix of the email address (userID: MAXMUST, firstname.lastname@example.org).
In the first step, a user is created with userName=MAXMUST@ibsolution.de and email=MAXMUST@ibsolution.de. He gets the userID MAXMUST.
In the second step we change the user with the userID MAXMUST to userName=MAXMUSTERMANN@ibsolution.de and email@example.com.
As a result, the user now has the userID MAXMUST and the email address firstname.lastname@example.org.
Challenge 7: Case sensitivity for NameID in SSO
Despite successful setup of the SSO, some users are unable to log in to SAP Analytics Cloud. Instead, cryptic error messages appear. The problem is reproducible for some users, while logging in works fine for other users.
Unlike many other implementations, the SAML implementation of SAC is case sensitive for SSO. This means that a user with the email address MaxMustermann@ibsolution.de in the identity provider cannot be assigned to the user email@example.com.
The solution to this problem is simple: in the SAC, email addresses should always be lowercase. In the identity provider a transformation for the NameID must be selected.
ToLowerCase() on Azure/ADFS
On SAP Cloud Identity Authentication, there is a transformation selection under Applications -> Select App -> Apply Function to Subject Name Identifier.
The connection of SAP Analytics Cloud to SAP Identity Provisioning Service is still facing some difficulties. The development team has already addressed many of the challenges mentioned. They will be improved in upcoming releases. For example, a new version (2.0) of the SCIM API will be released in summer 2022. Some other issues are more deeply rooted and will need to continue to be addressed with workarounds. As soon as there is news about the connection of SAC to SAP IPS, we will update the blog post accordingly.