I recently had the opportunity to work at length with the Security Assertion Markup Language Single Sign On (SAML SSO) and attribute mappings in SAP Analytics Cloud. As an old school SAP BusinessObjects admin, this was a significantly different experience than configuring the secLDAP plugin and I thought the experience warranted sharing. This post is relevant to any system owner of an SAP Analytics Cloud tenant, as user, teams, and role management are key tasks for any administrator.
To start, let’s define a target architecture and process flow. We will create it using components of SAP’s Business Technology Platform (BTP).
Special thanks to the SAP Cloud Identity Authentication Service help for input on the diagram above. In this scenario, we will integrate SAC with the Identity Authentication Service (IAS) on the SAP Cloud Platform. For those of you with a Cloud Platform Enterprise Agreement (CPEA), or CPEA, you can get your own IAS tenant by following the instructions here.
There are a number of for enabling various SAML workflows in SAC, but I didn’t see anything that offered a comprehensive view from both sides of the equation. That is, I didn’t find the configuration needed on SAC, and the Identity Provider (IdP), IAS. I’ll call out useful resources along the way that might be helpful in your own tenant as well.
As a first step, we need to enable SAML SSO according to the directions in the application help. The only additional info we need from the IAS instance is its metadata, which can be retrieved here:
https://[yourtenant].accounts.ondemand.com/saml2/metadata
The metadata provides SSO and Logout URL and the certificates necessary for the two applications to communicate. Before we can complete the setup in SAC, we need to register a new application inside the IdP.
The instructions for troubleshooting in https://apps.support.sap.com/sap/support/knowledge/en/2487567 were critical in identifying what SAML assertion attributes were present in my logon request.
Now that we have the initial SAML SSO configured, we can enrich the security model in the following ways:
Based on the default configuration, any valid user of the IdP would automatically be logged in to SAC. Now, let’s tighten the security up by creating an admin group that we grant access to, while denying access to users not in this group.
More complex rules can be added linking the values from multiple assertion attributes, as needed.
The final piece of the equation was to determine if I could fully automate the provisioning of new teams in SAC and map them to SAML attributes. This would ensure that when a new team is created, no administration needs to take place inside of SAC. Similarly, if a user leaves the company, we might want the IdP to also invoke the user’s deletion inside of SAC.
I couldn’t find a way to orchestrate this inside of IAS, nor were the SAML mappings available in the API, so for now I’ll consider it ‘not feasible’. If there is interest from the community on this type of integration, let me know in the comments and I can look into it further. For now, I hope you found this end-to-end example useful!
To start, let’s define a target architecture and process flow. We will create it using components of SAP’s Business Technology Platform (BTP).
Special thanks to the SAP Cloud Identity Authentication Service help for input on the diagram above. In this scenario, we will integrate SAC with the Identity Authentication Service (IAS) on the SAP Cloud Platform. For those of you with a Cloud Platform Enterprise Agreement (CPEA), or CPEA, you can get your own IAS tenant by following the instructions here.
There are a number of for enabling various SAML workflows in SAC, but I didn’t see anything that offered a comprehensive view from both sides of the equation. That is, I didn’t find the configuration needed on SAC, and the Identity Provider (IdP), IAS. I’ll call out useful resources along the way that might be helpful in your own tenant as well.
As a first step, we need to enable SAML SSO according to the directions in the application help. The only additional info we need from the IAS instance is its metadata, which can be retrieved here:
https://[yourtenant].accounts.ondemand.com/saml2/metadata
The metadata provides SSO and Logout URL and the certificates necessary for the two applications to communicate. Before we can complete the setup in SAC, we need to register a new application inside the IdP.
- Access the admin console of your IAS tenant at https://[yourtenant].accounts.ondemand.com/admin
- Click Applications and ‘+ Add’ at the bottom. I named my application Sunrise Analytics:
- Now we have some properties to configure. Here is the order of operations:
- Click SAML 2.0 Configuration, upload the metadata you downloaded from SAC, and save the result. IAS parses all the relevant URL and certificate data from the XML.
- Select Subject Name Identifier and select an attribute you want users to login with. I am using an SAP email addresses, so have selected E-mail.
You can see the various properties maintained on my user account:
- Since I am selecting E-mail, I’ll also update the Default Name ID Format.
- Next, we have a variety of options for asserting user attributes in IAS, but if your SAC tenant is hosted on a non-SAP data center, you have to ensure attributes follow a specific whitelisted format, specified here. Click Assertion Attributes and configure the minimum needed to populate the user properties.
- Finally, every user of SAC needs to have an attribute called Groups that is set to the value “sac”. We can do this under Default Attributes.
- At this point, we can complete the SSO configuration back in SAC. I set the user attribute to email and enabled dynamic user creation. This lets me provision new users directly from IAS.
- Now I should be able to login with my SAP email address. I had a little fun with the Branding and Layout tab in IAS.
- Finally, I can see the successfully mapped attributes in the user management page.
The instructions for troubleshooting in https://apps.support.sap.com/sap/support/knowledge/en/2487567 were critical in identifying what SAML assertion attributes were present in my logon request.
Now that we have the initial SAML SSO configured, we can enrich the security model in the following ways:
- Enable risk-based authentication in IAS to ensure only certain users get access to SAC
- Assign users to teams dynamically based on SAML attributes
- Assign users to roles dynamically based on SAML attributes
- Explore the SCIM API for user/role/team management
Based on the default configuration, any valid user of the IdP would automatically be logged in to SAC. Now, let’s tighten the security up by creating an admin group that we grant access to, while denying access to users not in this group.
- Inside the IAS admin console, click Users & Authorizations > User Groups > Add. In my case, I’ll create a new group called sunrise_admin
- Next, I’ll assign myself to the group under User Management.
- Now we enable Risk-Based Authentication under Applications & Resources by selecting our application (mine is called Sunrise Analytics) and then the Authentication and Access section.
- Add a rule granting access to the sunrise_admin group and update the default action to Deny. Don’t forget to save the changes before returning to the previous menu.
- Next, if we want to leverage this group in SAC, we need to add it to an SAML Assertion. I found this a little counterintuitive, but the attributes have to literally be named “custom1”, “custom2”, “custom3”, etc. and then they show up inside of SAC.Go back to the Trust tab and add a new entry to the Assertion Attributes section called custom1.
- On my next logon to SAC, I can see the new attribute value in the SAML assertion.
- Now I can create an Admin team and dynamically assign access to it based on the new custom1 attribute. It appears in the list dynamically based on what is returned in your assertion!
- Similarly, I can assign users to roles using the same mechanism. In this case, I’ll assign the Admin role.
More complex rules can be added linking the values from multiple assertion attributes, as needed.
The final piece of the equation was to determine if I could fully automate the provisioning of new teams in SAC and map them to SAML attributes. This would ensure that when a new team is created, no administration needs to take place inside of SAC. Similarly, if a user leaves the company, we might want the IdP to also invoke the user’s deletion inside of SAC.
I couldn’t find a way to orchestrate this inside of IAS, nor were the SAML mappings available in the API, so for now I’ll consider it ‘not feasible’. If there is interest from the community on this type of integration, let me know in the comments and I can look into it further. For now, I hope you found this end-to-end example useful!
- SAP Managed Tags:
13 Comments
| User | Count |
|---|---|
| 14 | |
| 11 | |
| 11 | |
| 10 | |
| 10 | |
| 8 | |
| 7 | |
| 7 | |
| 7 | |
| 7 |
