Technical Articles
Simplify User Administration in SAP Analytics Cloud
SAP Analytics Cloud is positioned by SAP as the strategic cloud-based solution for all analytics. In the coming years, an increasing number of customers will start, or extend, their cloud investments and shift from existing on-premise BI solutions to SAP Analytics Cloud to connect people, information and ideas to enable fast and confident decision making. To support this shift, it’s crucial that SAP offers capabilities to seamlessly integrate with other components in the IT landscape, especially for authentication and authorization to minimize support effort required.
In this blog series I will show you how you can simplify the user administration in SAP Analytics Cloud and minimize the effort required by ensuring that a user profile gets dynamically created with single sign-on access to the SAP Analytics Cloud tenant along with automatic assignment of the user’s properties, required role(s) and team(s) based on SAML attributes.
Manage Users: Setup Dynamic User Creation via Single Sign-On
For a user to be able to access SAP Analytics Cloud, there is basically one prerequisite: a user profile needs to exist. With this user profile in SAP Analytics Cloud, a user can successfully login by providing an email address and a password (by default stored in SAP Cloud Identity).
SAP Analytics Cloud supports multiple ways to create (and maintain) user profiles:
- Manually;
- Import from a file;
- Import from Active Directory;
- Dynamic user creation.
Given the fact that we are aiming to minimize the effort required for user administration, the latter option, dynamic user creation, sounds like the way to go! This option means that a user profile is automatically created when a user accesses the SAP Analytics Cloud tenant. Let’s see what you need to do to enable dynamic user creation in SAP Analytics Cloud.
In this example we are using an SAP Analytics Cloud tenant in an SAP data center, also referred to as an NEO tenant. You can determine where your tenant is hosted by inspecting the SAP Analytics Cloud tenant URL:
|
Setup Single Sign-On
The option to dynamically create users is part of enabling single sign-on on the SAP Analytics Cloud tenant. A benefit of enabling single sign-on is that users don’t have to authenticate by typing in an email address and password. A prerequisite is that the user must have a corresponding user profile in the Identify Provider (IdP).
SAP Analytics Cloud supports configuring single sign-on authentication based on an IdP that supports SAML 2.0. In our example, we are using Azure Active Directory (AD). If you want more information on how the single sign-on SAML protocol is supported in Azure AD, please read the following article: Single Sign-On SAML protocol.
Set up an Application in Azure
Before we can enable single sign-on in the SAP Analytics Cloud tenant we have to create an application in Azure AD. Integrating SAP Analytics Cloud with Azure AD provides you with the following benefits:
- You can control in Azure AD who has access to SAP Analytics Cloud.
- You can enable your users to be automatically signed-in to SAP Analytics Cloud (Single Sign-On) with their Azure AD accounts.
- You can manage your accounts in one central location – the Azure portal.
Collect SAP Analytics Cloud Metadata
To create the Azure AD application, metadata from the SAP Analytics Cloud tenant is required. Make sure you perform the following steps to collect the metadata:
- Browse to the SAP Analytics Cloud tenant and log in with the user that has the ‘System_Owner’ role. This is a prerequisite to perform the necessary configuration steps to collect the metadata. Without the ‘System_Owner’ role, you are not allowed to change the ‘Authentication Method’.
If necessary, you can assign the ‘System_Owner’ role to a different user via ‘Menu’ – ‘Security’ – ‘Users’. Select a user and click on ‘Assign as System Owner’.
- Access the Security menu via ‘Menu’ – ‘System’ – ‘Administration’ – ‘Security’. Click on ‘Edit’ in the upper-right corner to make changes to the configuration.
- Switch the ‘Authentication Method’ from ‘SAP Cloud Identity (default)’ to ‘SAML Single Sign-On (SSO)’.
- Click on ‘Download’ and open the XML file.
- Copy and paste the following values from the XML file:
- entityID: [tenant].[location].sapanalytics.cloud. This will be used as ‘Identifier’.
- SingleSignOnService Binding location: https://authn.[location].hana.ondemand.com/saml2/sp/acs/[subaccount]/[subaccount]. This needs to be filled in later on as ‘Reply URL’.
- Click on the ‘Cancel’ icon to discard the current changes and revert to ‘SAP Cloud Identity’ authentication for now.
Create an Application in Azure
Now that we have collected the metadata from our SAP Analytics Cloud tenant, we can create an application in Azure AD:
- Browse to your Azure portal and in the left navigation panel, click on ‘Azure Active Directory’.
- Navigate to ‘Enterprise Applications’ and then select the ‘All applications’ option.
- To add a new application, click the ‘New application’ button on the top of the dialog.
- Create a custom application and enter a name. In our example, we will use ‘SAP Analytics Cloud Trial’.
Next step is to setup Single sign-on using SAML.
- Select ‘Single sign-on’.
- Click on the ‘Edit’ icon to set up the ‘Basic SAML Configuration’.
- Enter the ‘Identifier’ and the ‘Reply URL’ collected from the XML file of the SAP Analytics Cloud tenant and click ‘Save’. Another option is to upload the metadata file to auto-populate these fields.
- The next step is to save the download the ‘Federation Metadata XML’ file. We need this file to enable the application to act as IdP in SAP Analytics Cloud.
- The final step is to grant access to the application we just created in Azure. Please go to ‘Users and groups’ and click on ‘Add User’.
- Because we want to enable dynamic user creation a group should be added that contains all target users within your organization which should be allowed to use SAP Analytics Cloud.
Enabling a Custom SAML Identity Provider
Now that we configured the application in Azure AD, let’s start with enabling SAML single sign-on in our SAP Analytics Cloud tenant.
- Access the Security menu via ‘Menu’ – ‘System’ – ‘Administration’ – ‘Security’. Click on ‘Edit’ in the upper-right corner to make changes to the configuration.
- Switch the ‘Authentication Method’ from ‘SAP Cloud Identity (default)’ to ‘SAML Single Sign-On (SSO)’.
- Click on ‘Upload’ to upload the metadata.xml file of our Azure AD application and click ‘OK’.
- In Step 3 select the user attribute to map to our IdP. Select ‘Email’ and check the box to enable ‘Dynamic User Creation’.
- In Step 4 we are verifying our account against Azure AD. Provide the ‘Login Credential’ and click on ‘Verify Account’.
- A ‘Login URL’ is displayed. Use the ‘Copy’ icon to select and copy the URL and paste it into a private browser session (incognito mode).
- Once the private browser session displays the message below, the SAML account has been verified successfully.
- Click ‘Save’ to save the configuration changes.
- Click ‘Convert’ to change the authentication method to SAML single sign-on.
Ok, great! We have now successfully enabled SAML single sign-on on the SAP Analytics Cloud tenant.
Now let’s see what happens when a user that doesn’t have a user account browses to the SAP Analytics Cloud tenant URL.
Validate Dynamic User Creation
Ask one of your users to browse to the SAP Analytics Cloud tenant and validate if the user gets single sign-on access. Please ensure that the user is added to the AD group that has been granted access to the Azure AD application we created.
Once the login is successful you can see that the user is not capable of doing much. This is due to the lack of assigned roles and teams. But before we look at how to automatically assign those, we first want to use SAML to map the user properties maintained in the IdP.
Map SAML User Properties
The benefit of mapping SAML User properties is that the user profile in SAP Analytics Cloud is updated with the latest information from your SAML IdP. Each time a user logs on to SAP Analytics Cloud, the latest information will be read and updated in their SAP Analytics Cloud user profile.
Submit a Support Ticket
Using SAML attributes to map to user properties is not enabled by default. Enabling SAML attributes must be requested by creating an SAP support ticket using the component LOD-ANA-BI. Please include your tenant URL. SAP support will take care of the request and will confirm in the ticket when the necessary steps are executed.
User Attributes in Azure
Another prerequisite for mapping user properties to SAML attributes is that the correct SAML attributes are exposed by the application in Azure. Furthermore, we need to change the ‘namespace’ value to a blank (or something else), otherwise, SAP Analytics Cloud will not allow mapping because the default namespace contains special characters.
Please follow the next steps:
- Browse to the Azure portal and click on ‘Enterprise applications’ – ‘All applications’.
- Select ‘Single sign-on’ and click on the ‘Edit’ icon for the ‘User Attributes & Claims’ section.
- Add a new claim or change an existing one based on your requirements and set up in Azure AD. At least make sure that the namespace for each attribute you wish to expose is blank or at least doesn’t contain any special characters.
- Click ‘Save’.
If your SAP Analytics Cloud tenant is running in a non-SAP data center you must configure your SAML IdP to map user attributes to the following case-sensitive white-listed assertion attributes:
Make sure you add the attribute ‘Groups’ with a value of “sac” as displayed above. This is mandatory to make sure that the custom1, custom2, etc. attributes become visible in SAP Analytics Cloud when performing a SAML mapping.
If you are using the SAP Cloud Platform Identity Authentication service as your IdP, map the Groups attribute under Default Attributes for your SAP Analytics Cloud application. The remaining attributes should be mapped under Assertion Attributes for your SAP Analytics Cloud application.
More information can be found here: Enabling a Custom SAML Identity Provider.
Map SAML Attributes
Now that all the SAML attributes are configured properly let’s set up the mapping of SAML User properties:
- Access the ‘Users’ menu via ‘Menu’ – ‘Security’ – ‘Users’. Click on ‘Map SAML User Properties’ in the upper-right corner to make changes to the configuration.
- The ‘Map SAML Attribute’ dialog will display. Here we define which ‘SAML Attribute’ is mapped to which ‘Target Property’.
- Select the ‘SAML Attribute’ for each ‘Target Property’ and click ‘Save’. If you want to add additional mappings use the ‘New mapping definition’ icon.
- Click on ‘Save’.
- As displayed below the user properties in your SAP Analytics Cloud tenant are read from the linked Identity Provider each time a user logs in.
Mapping Role(s) using SAML Attributes
So far, we managed to enable single sign-on to the SAP Analytics Cloud tenant including dynamic user creation and we mapped the user properties to SAML attributes maintained in our IdP, so we already reduced the support effort required and simplified user administration in SAP Analytics Cloud. But the annoying thing is that these dynamically created users are not able to do much, yet!
The permissions to perform certain actions, like viewing or creating stories are maintained via ‘Roles’. Based on your license, SAP Analytics Cloud comes with several pre-defined roles for BI, Planning, Predictive, etc. Below an example of the permissions for the standard ‘BI Content Viewer’ role is displayed.
The great thing about SAP Analytics Cloud is that we can automatically map roles to users based on SAML attributes. This means that when a user is dynamically created, one or multiple roles will be assigned based on a specific value in one of the SAML attributes.
In our example, we want to use the Group claim that contains the values of the security groups but before this is available as part of the SAML assertion we first need to edit the manifest of the application:
Edit Manifest
To be able to use security groups as a SAML attribute, we need to edit the application manifest in Azure AD. Please follow the next steps:
- Select ‘Azure Active Directory’ in the Azure Portal, and then select ‘App registrations.
- Select the application we just configured from the list of applications.
- From the app’s overview page select ‘Manifest’. A web-based manifest editor opens, allowing you to edit the manifest within the portal. Optionally, you can select Download to edit the manifest locally, and then use Upload to reapply it to your application. Change the value of the “groupMembershipClaims” from ‘null’ to “SecurityGroup” and click on ‘Save’.
To ensure the Group claim can be properly consumed by SAP Analytics Cloud, the namespace can’t contain any special characters. By default, the namespace of a SAML attribute is used for the mapping instead of the name of the attribute. To avoid issue we need to make sure the namespace is blank.
- Browse to ‘Enterprise Applications’ and select our application.
- Click on ‘Single sign-on’ and select ‘Edit’ for the ‘User Attributes & Claims’ section.
- Click on ‘Edit’ for ‘Groups returned in claim’.
- Select ‘Security groups’ and tick the checkbox that allows customization of the ‘Name’ and the ‘Namespace’. Enter a name for the claim, in our example ‘Groups’.
- Click on ‘Save’.
Configure Role Mapping
Let’s share how you can setup you SAP Analytics Cloud tenant to use the Group claim as SAML attribute to automatically assign users to a role:
- Go to ‘Roles’ via ‘Main Menu’ – ‘Security’ – ‘Roles’. Click on the Role that needs to be mapped to a SAML attribute value.
- Click on the ‘Open SAML Role Mapping’ icon.
- In this dialog, we can specify based on which value of a SAML attribute the role should be assigned to a user in SAP Analytics Cloud.
- Select one of the attributes which are available for mapping from the drop-down menu ‘SAML Attribute’. The list of attributes displayed match the ‘SAML Token Attributes’ which are part of our Azure AD application. In our example, we are using an attribute called ‘Groups’ which exposes the values of the ID of the Azure groups a user is a member of. This has been enabled earlier by editing the manifest to issue the group claim.
- Click on ‘Save’.
Each time a user accesses the SAP Analytics Cloud tenant the role(s) assigned to the user will be updated based on the values in the SAML Token.
Mapping Team(s) using SAML attributes
The final step is granting users access to stories and applications within the SAP Analytics Cloud tenant. This is managed via the sharing permissions that can be set via ‘Menu’ – ‘Browse’ – ‘Folders’. For each folder and file, you can define the ‘Sharing Settings’ based on users and/or teams. The sharing settings define if a user has access to a certain object or folder and which actions the user can perform.
Users can be grouped into teams and can be a member of zero, one or multiple teams. By using teams in applying sharing settings we can create an authorization model in SAP Analytics Cloud. Let’s look at how we can automate team assignments, like assigning roles using SAML attributes.
- Go to the ‘Menu’ – ‘Security’ – ‘Teams’.
- Click on the checkbox in front of the team and click on the ‘Open SAML Team Mapping’ icon.
- In this dialog, we can specify based on which value of a SAML attribute the team should be assigned to a user in SAP Analytics Cloud.
- Select one of the attributes which are available for mapping from the drop-down menu ‘SAML Attribute’. The list of attributes displayed match the ‘SAML Token Attributes’ which are part of our Azure AD application. In our example, we are using an attribute called ‘Groups’ which exposes the values of the ID of the Azure groups a user is a member of. This has been enabled earlier by editing the manifest to issue the group claim.
- Click Save.
- The mapping is finalized. When a user will log in to the tenant team membership will be assigned based on values in the SAML Token.
Summary
By enabling SSO to you SAP Analytics Cloud tenant, map the user properties and map teams and roles based on group membership administrated in your custom IdP you can reduce the efforts around user administration. This is an important step for further adaptation of Cloud-based solutions in your IT landscape.
Hi Martijn
SSO topic briefing is good
Regards
Bose
Hi Bose,
Thanks!
Kind regards,
Martijn van Foeken | Interdobs
Hi Martijn,
Great blog! Thank you!
Are there any plans to enable an automatic mapping between SAC Teams and BW roles (instead of AD groups)?
Thank you, Alexey
Hi Alexey,
Thanks! I'm not aware of such plans. It's more likely, in my opinion, to map BW roles based on AD groups. I have submitted a similar request as an improvement for SAP HANA: 237983 - Map roles to SAML attribute value. Perhaps you can submit a similar request and share the link as a reply.
Kind regards,
Martijn van Foeken | Interdobs
Hi Martijn,
This is an excellent blog post, I was just looking into SAML attributes for Team and Role assignments.
Thank you
Andrew
Thanks Martijn van Foeken this is a great piece of work, much obliged! cheers, H
Thanks Martijn van Foeken for this very detailed documentation. Today we tried to configure "Mapping Roles Using SAML Attributes", BUT IN THE SAC "Configure Role Mapping" we could not SELECT an attribute called ‘Groups’. We are only able to select the SAML Default attributes in SAC.
Do you have an idea what could be missing?
Thank you for your help, Regina
Hi Regina,
Which IdP are you using? If it's Azure AD, please follow the steps in the section 'Edit Manifest'.
Kind regards,
Martijn van Foeken | Interdobs
Hi Martijn,
we are using Azure AD and tried to configure everithing like you described. Is the configuration different, if SAP Analytics Cloud is running on a non-SAP data Center, liek described in
"Enabling a Custom SAML Identity Provider":
https://help.sap.com/viewer/00f68c2e08b941f081002fd3691d86a7/release/en-US/3651184dad944aa2b361ad029a7a8cae.html
you must configure your SAML IdP to map user attributes to the following case-sensitive white-listed assertion attributes:
Thank oyu for your help, Regina
Hi Regina,
Can you share a picture of how you assigned the attributes in Azure AD for the application regarding Groups, custom1, custom2, etc. for non-SAP datacenters?
Kind regards,
Martijn van Foeken | Interdobs
currently we only tested the configuration from your documentation:
Hi Regina,
The claim 'Groups' should be added with a value 'sac' instead of selecting an attribute. The next step is to add a claim called 'custom1' and assign this the attribute user.groups as value.
This should do the trick.
Kind regards,
Martijn van Foeken | Interdobs
Hi Regina/Martijin,
Hope you are doing good,
We have a similar requirement and we are trying to use custom1 attribute for role and teams assignment.
Could you please let me know if custom1 should be added as group attribute or user attribute and also how you are setting Groups as "sac" in Azure. Could you please share the claims screen-shot.
Regards,
Gaurav
Hi Martijn, thanks for the article but we too are stuck on getting role/team assignments from SAML claims going on a non-SAP DC. Did you mean you've got this working? How so please?
Hi Jay,
Yes, I have this working.
Make sure you add a claim called 'Groups' with a fixed value 'sac'. Then add a second claim called 'custom1' and select the attribute that contains group information, like user.groups.
As a result both claim should be visible in your SAML assertion ticket. In SAC you should see custom1 as available attribute to perform the mapping.
Kind regards,
Martijn van Foeken | Interdobs
Hi Martijn,
I think the blog is for SAC deployed on SAP data centers right? because for SAC deployed on CF, the custom1,custom2, needs to mapped to either a group or role.
Thanks,
Shailu.
Hi Shailu,
Yes, the blog is limited to SAC deployed on SAP data centers. I will extend this in the future with how it works for CF tenants.
Kind regards,
Martijn van Foeken | Interdobs
Thanks Martijn.
Hi Shailu,
I added some text and a screenshot on how to set up the Groups and custom1, custom2, etc. attributes for CF tenants.
Regina Böhm
Kind regards,
Martijn van Foeken | Interdobs
Hi Shailu,
could you please provide screenshots from the configuration you showed us this morning?
Thank you, Regina
Few notes when OKTA is used as IDP, and to map AD groups to Team/ Roles.
This is a great way to automate user creation!
How about automatic user deletion? If an employee leaves the company the user needs to be removed. Is it possible to remove a user after a certain period? What other ways are supported instead of removing the users manually or over an API call?
Hi Andreas,
Unfortunately the two options you mention are the ones available today:
There is no option where you can set that users being inactive will be disabled and/or deleted after x amount of time in SAP Analytics Cloud. If you delete users from your custom IdP users can't login anymore but they will remain in the tenant and hence consume a named license.
I noticed there is a influence request with status accepted focussed on delivering the feature to disable a user: https://influence.sap.com/sap/ino/#/idea/232198
Kind regards,
Martijn van Foeken | Interdobs
Thank you very much for the quick and clear answer!
Hi Martijn,
thank you for your detailed explanation here in the blog.
Do you also have experience with the SAML configuration in IAS/IDP?
I'm currently working on a project in which we want to dynamically create users in SAC who log on via SAML. The mapping also works so far and is configured correctly and the dynamic user creation works fine. Now we want to assign new users directly to a team in SAC by default. We have configured the 'Groups' attribute with value 'sac' in the IAS, but in SAC under Security->Teams->SAML Mapping we cannot select Groups in addition to the three standard attributes email, familyName and givenName.
Do you have any idea what perhaps we are currently doing wrong?
Thank you in advance!
Best regards,
Philipp
Hi Philipp,
You should a a attribute called 'Groups' with the value "sac". Furthermore you include a claim with the name 'custom1' and assing 'user.groups' as value. Check with a SAML tracer whether the correct attributes are part of the SAML request.
Kind regards,
Martijn van Foeken | Interdobs
Hi Philipp Mueller ,
if your SAC Tenant is based out of AWS infrastructure, you should define CUSTOM1, CUSTOM2 attributes to map it to teams in SAC.
Thanks,
Shailu.
Hi Shailendar,
Hope you are doing good,
Wanted to check how you are configuring custom1 attribute in Azure. If the value of this claim should be "user.groups" i.e. fixed value? For us the requirement is, user should get access based on AD group but with fixed value we are not able to proceed. if possible, could you please share the claims screen-shot?
Best Regards,
Gaurav
Hi Gaurav & all others,
It seems that for newer Versions of Azure AD the process is a bit different.
1) you seem not to need to edit manifest
2) you add attribute claim Groups - "sac"
3) you add a group claim (different menu item in the top area) referencing Security Groups - Source Attribute sAMAccountName but then you need to set as Customize name custom 1 instead of Groups
This will then add the custom1 user.groups claim to the addtional claim list.
Hi Axel,
Yes, you are correct. I'm currently writing an E-Bite on this topic which will be published in Feb. 2022.
Kind regards,
Martijn van Foeken | Interdobs
Hi Martijn,
we would like to map SAML property NameID to User-Id instead of FirstName LastName because this property never changes the value for our users. We are on a non-SAP data center. We did not manage to do so. Is it possible?
Regards
Sabine
Hi Sabine,
I believe that the USERID can't be mapped, most probably due to the fact that it can be selected as a mapping attribute for setting up SAML SSO.
Kind regards,
Martijn van Foeken | Interdobs
Hi Martijn,
Great post, as SAP referred me to your blog when reporting an issue with the SAML config.
We have just been migrated from the NEO tenant to the Cloud Foundary tenant on NON SAP DATA CENTRE. However none of the configuration mentioned seem to work for me.
I do not see the custom1,custom2 fields as an option for the role mapping. I have also set groups with default sac as part of the attribute claim.
Not sure what I am missing as this is the only options I see:
Regards,
Gowri
Hi Gowri,
First of all, thanks for the compliment! Great to hear that SAP is actually referring to my blogs ;-).
I should go through it however and see where it needs some updates. However for Cloud Foundry you need to do this:
Add an additional claim named 'Groups' with a constant value "sac". Just type it in. Secondly add 'custom1' and select user.groups from the dropdown box.
This should do the trick!
Kind regards,
Martijn van Foeken | Interdobs
Hello Martijn van Foeken,
Thanks for the great example and screenshot for CF. Could you please let me know if the user attributes in SAC get updated automatically based on the latest user information in Azure? As in the second screenshot in this comment, the namespace is not blank and it includes special characters that don't match what you wrote in the blog above
Many thanks,
Wu
Hi Martijn,
Very nice blog post. I can see the integration between Azure AD and SAC directly.
But as IAS has been postioned by SAP as the central bridge to connect different cloud solutions, and I know as well IAS can be the proxy between Azure AD as IDP and SAC/BTP as the applicaiton. What do you suggest here for customers? Shall they go to IAS as proxy or directly integrate Azure AD as IDP?
Thanks!