Skip to Content
Technical Articles
Author's profile photo James Rapp

SAML SSO and User Management in SAC with SAP Identity Authentication Service

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:



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.


  1. Access the admin console of your IAS tenant at https://[yourtenant]
  2. Click Applications and ‘+ Add’ at the bottom. I named my application Sunrise Analytics:
  3. Now we have some properties to configure. Here is the order of operations:
  4. 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.
  5. 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:
  6. Since I am selecting E-mail, I’ll also update the Default Name ID Format.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. Finally, I can see the successfully mapped attributes in the user management page.

The instructions for troubleshooting in 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.

  1. Inside the IAS admin console, click Users & Authorizations > User Groups > Add. In my case, I’ll create a new group called sunrise_admin
  2. Next, I’ll assign myself to the group under User Management.
  3. 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.
  4. 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.
  5. 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.
  6. On my next logon to SAC, I can see the new attribute value in the SAML assertion.
  7. 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!
  8. 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!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo John Mrozek
      John Mrozek

      Nice one, Jim!

      Author's profile photo Sven Swennen
      Sven Swennen

      First of all very nice blog!
      I came upon this as I have to implement this later on myself and this is by far the best blog I came across for IAS with SAC, so I'm not worried at all about this install thanks to your blog. But my question here is regarding your last part for the IdP to invoke user deletion in SAC when someone would leave.
      Something like this didn't cross my mind until you posted it here and I was wondering if you think this would already by feasible or not? Is there already something foreseen to do this?

      Author's profile photo James Rapp
      James Rapp
      Blog Post Author

      Hi Sven,

      I'm sorry I missed your comment last year! Hopefully you found what you were looking for, but if not, I would totally recommend this collection of SCIM API scripts that my colleague actively maintains:

      This shows you how to interact with users, groups, and teams on SAC programmatically and could be used to automate cleanup tasks.

      There are additional mechanisms available on IAS to act as a proxy to your corporate IdP:

      And it has a SCIM API of its own to manage SP users:

      Finally, and in the interest of completeness, you might also use SAP Identity Provisioning Service (IPS) to manage some of this automatically:

      Hope these resources are helpful to you or somebody else!

      Author's profile photo Sven Swennen
      Sven Swennen

      Thank you very much on the info! The task to implement this went to a colleague of mine and it got postponed because of other projects. so I'm sure this will still come in handy when we do the setup Q1 next year.

      Author's profile photo Bill Liu
      Bill Liu

      Thanks Jim,


      For the last piece of the solution, if a user gets terminated from the company then the user can be disabled in the central IdP. The dynamically created SAC technical user doesn't have password, the IdP based authentication would protect the system from access of the terminated user. Also, deletion of SAC user is risky act as it would delete the owned objects of the user in his workspace. I don't believe that SAC product will introduce such feature in the future.

      Best regards!



      Author's profile photo James Rapp
      James Rapp
      Blog Post Author

      Hi Bill,


      Thanks for the comment on this old post of mine. You may be right but there is also an element of license management that goes along with this. You wouldn't want to tie up valuable planning licenses on users who are no longer with the company. However, I get your point and agree that this cleanup of user accounts and reassignment of any content is better suited to an administrator.



      Author's profile photo Bill Liu
      Bill Liu



      Yes, the dangling user who occupies a valuable license would need extra effort to cleanse up. I wish there would be a solution to propagate a user status from IdP to SP to disable a shadow user and to release the license occupation too.


      Thanks again for the excellent blogging!


      Best regards!


      Author's profile photo Philipp Rammos
      Philipp Rammos

      Dear James,

      thanks for this great article. Unfortunately we have an issue using the SAC content network, is this a known limitation or do we need any special attributes in IAS?

      If we use direct user assignments in SAC everything works as expected. As soon as we use authentication via IAS the content network is broken and does not load anymore. Everything else is working fine, but not the content network.

      Currently we are implementing the new Sustainability Control Tower (SCT) solution where we have the exact same issue with the content network. Works with direct user assignment via S-User ID but not via customer IAS.

      (we have unresolved OSS cases in regards to that)

      Do you have any idea? Thanks in advance 🙂


      Author's profile photo James Rapp
      James Rapp
      Blog Post Author

      Hi Philipp,

      Thanks for your comment and sorry you are having issues with the Content Network. I am able to access it with no issues using my own IAS tenant. Are you assigning permissions to SAML-based users? Hopefully, the OSS case gets resolved and finds the answer for you.



      Author's profile photo Philipp Rammos
      Philipp Rammos

      Hi Jim,

      thanks for your fast reply 🙂

      Indeed we are assigning permissions to SAML users. The default group setup with the 'sac' value has been configured and all other steps are working as well.

      Fingers crossed the OSS Team finds the answer.