Part 3: Identity Providers for SAP CP in Practice

This is part 3 of my blog series about cloud architecture on SAP Cloud Platform. You can find the overview page here.

In my previous blog about user management, you learned about the different identity providers and user types that are typically involved when it comes to productive SAP CP scenarios. After the theory from the last blog, I now want to explain how all this can be configured and used in practice with SAP CP.

First of all, I argue that there are three use cases when it comes to application users:

• Internal: All users of your SAP CP application are internal users of your company/client.
• External: All users of your SAP CP application are external users (not counting developers, support users, project leads). This scenario is typical if you develop an application for your own customers (which are most often not part of your company’s internal user management, e.g. an LDAP), your partners, or completely external individuals on the internet.
• Hybrid: Users of your SAP CP application could either come from your internal company, or from your external customers, or partners, or completely external altogether.

For the internal use case, you most probably already have all users in some kind of corporate user store/ corporate identity provider. It could be a company’s LDAP, SAP User Management Engine, or a Microsoft Active Directory. In this case, your easiest and most structured approach would probably be to securely integrate this user management with your SAP CP Sub-Accounts so that internal users can access SAP CP applications with their normal users and passwords. I am sure that most internal end-users will expect this to work. Also, in my opinion, it results in a much cleaner architecture if you manage all your internal users in one central location and not in an internal system for internal user cases and in an external cloud identity provider for your cloud use cases.

In my SAP CP projects, I made particularly good experience integrating corporate user managements via SAML endpoints. Microsoft’s Active Directory Federation Services (ADFS), for example, allows you to expose your Active Directory users via a SAML 2.0 endpoint. Integrating such a SAML endpoint with SAP CP is straightforward and a very secure and standardized approach to allow your internal users to access your cloud applications. It’s also easy to not only verify users identities’ (authentication) with such a SAML endpoint but you can also publish user group information via SAML assertion attributes and therefore also conduct parts of the authorization process via SAML. I will write about the details of user groups, roles, and permissions in a later blog but in short: with SAML assertion attributes you can expose a user’s group membership with the SAML endpoint and reuse all your company’s group definitions from your central user management into the SAP CP. Very convenient…

For the external use case, I would recommend to use a SAML identity provider. SAP, for example, offers a SAML identity provider (SAP Cloud Platform Identity Authentication or in short, SCI). I would certainly recommend giving SCI a try for your projects as SCI can be tightly integrated with SAP CP. However, SCI is not part of SAP CP and in principle, every other SAML identity provider will also work. Managing external users in an identity provider that is not inside your corporate network has many advantages:

• For projects that should be delivered within a short timeframe, integrating with SCI can be much faster than getting the AD-administrators to configure their ADFS correctly.
• You do not have to expose your Active Directory “publicly” via ADFS. Although it is a common thing to do and from what I have seen, security colleagues were always fine with that, but it could be that your company does not want ADFS SAML endpoints that are accessible from the internet.
• Especially for the external use case where you have users, who you most likely don’t want to maintain inside your corporate AD, an external SAML identity provider helps keeping your corporate identity management “clean”.

Now, most interesting, of course, is the hybrid scenario. Here, you have an application that is accessed by external users and internal users alike. Of course, you do not want to copy or replicate all internal users from your corporate identity provider to your SCI tenant (trust me, a single source of truth for your user information is a very convenient thing in contrast to constantly syncing different identity providers). On top of that, you probably don’t want external users in your corporate identity provider. So ultimately, you’ll want to maintain external users in SCI and your internal users in your corporate user management. In order to keep maintenance effort and cost as low as possible, you should integrate both identity providers to your application’s HCP Sub-Account. In the Cloud Cockpit under Security -> Trust, you can add multiple trusted identity providers easily. Of course, the SAML assertion attribute mappings will be different (we cover this in the next blogs), but you can reuse the same SAP CP user groups (Security -> Authorization) for all trusted identity providers. Once you added both identity providers to the Sub-Account, your external users could use SCI for authentication (and authorization) and your internal users could access the SAP CP application with their “normal” user names from the internal network.

The only small downside of this approach is the following: you’ll have to use an URL parameter in order to control which identity provider is used for the authentication. You can configure one identity provider as the default so if no parameter is specified, this identity provider is used. I typically set SCI as the default identity provider so that external customers can use the simpler URL without the parameter. Internal users will then have to access the application URL with the URL parameter “?saml2idp=<Name of the corporate identity provider>”. From my point of view (and my customers’ points of view until now), this was always an acceptable restriction.

Before we look at the final architecture recommendation, let’s go one step further in terms of controlling your two identity providers. Let’s assume an internal user wants to access a SAP CP application while he or she is on the move and not within the corporate network. Of course, the SAML authentication will redirect the user to the publicly available SAML endpoint for authentication which is exactly what you want. But an internal user who wants to access the same HCP application while sitting in the office (and therefore the internal network), will also be forwarded to the public ADFS endpoint. In case you do not want that, here is a neat trick: Just modify your internal DNS configuration so that the URL of the public ADFS endpoint is routed to the ADFS not via the internet but directly to the ADFS via the internal network. Obviously, with this setup, you do not leave your internal network for authentication which would be a bit odd if you are already inside the corporate network. Also, internal users can therefore use the same URL in every network.

So let’s look at my recommendation:

The external user (red) is authenticated against the SCI. Internal users who are in the office are authenticated against the internal endpoint of your ADFS so the authentication communication remains internal in the company. Internal users who are currently not inside the internal network are authenticated against the public ADFS endpoint without having to use a different URL.

A trusted identity provider is normally used for multiple applications at the same time. Ideally, you have as few different identity providers as possible. If you then have multiple SAP CP Sub-Accounts for multiple projects, of course, those Sub-Accounts will be connected to the same identity provider tenant. I would give you the following recommendations:

• Because of the fact that the identity provider is used by multiple applications, it should not be managed by the development teams of the individual projects. You’ll need to involve the IT services of your company and let them manage the cloud identity providers. Just as you already do it with the corporate identity provider (you wouldn’t give edit permissions to your Active Directory to the SAP CP project team, so then don’t do it for the cloud identity provider either).
• You can also receive a second SCI tenant from SAP for your non-productive landscape. It could be a good idea to maintain two identity providers to separate productive and non-productive use cases. You could then maybe also give more permissions to the project teams on the non-productive SCI tenant.

A possible landscape could look like this:

One last use case I have not told you about is that you could also add a SAML identity provider from a third party. So let’s assume you build an application for your customers and deploy it to SAP CP. But maybe, you do not want to manage the users yourselves or you want to give your customers the opportunity to manage users of the application by themselves. In these cases, you can simply integrate your customers or partners SAML identity provider with your SAP CP Sub-Account so that users who already have an account on those identity providers and who are already managed there can directly use your SAP CP application.

One last remark: There are other ways to integrate your internal user management with SAP CP. You can try to integrate the Active Directory directly via the Cloud Connector or also SCI can be connected via a reverse proxy to your corporate identity provider. Also, SCI features some methods like SPNEGO and other integrations so that you could also integrate your user management without a public SAML endpoint. In practice, however, I always struggled with the complexity of those approaches and as a public SAML endpoint is state-of-the-art in my mind (just take accounts.sap.com as an example), I would recommend this approach to you. Also, authentication and authorization are very critical steps and the more complex your approaches are, the more likely you create potential security issues… simplify!

I hope this blog helped you in understanding how to use the different identity providers in practice. In the next blogs, I will explain how roles, permissions, and groups work on SAP CP and how that influences your application from a software architecture perspective.

Stay tuned and let me know your thoughts on the recommendations for this article!

Cheers, Merry Christmas and a Happy New Year to all of you!