Introduction
With the ‘Integration Plan in the Cloud’ SAP introduced distinct suite qualities that characterize SAP’s intelligent suite of seamlessly integrated applications. The recently updated CIO Guide for Identity Lifecycle in Hybrid Landscapes sketched a reference architecture model for Identity Access Management (IAM). In this blog post we want to further detail this architecture model with a focus on authentication and single sign-on. We will concentrate on employee related integration scenarios (‘B2E’).
Goal is to share insights how SAP envisions to support single sign-on for hybrid landscapes. We will consider the following aspects: the IAM tenant model, identifiers, multi-factor authentication and typical reference architecture scenarios for hybrid landscapes.
It is obvious that such a blog will not be able to provide answers for all questions on how to setup single sign-on in a specific landscape, the intention is rather to provide food for thought for what to take into account.
Side remark: there is a corresponding blog dealing with reference architecture for identity lifecycle posted by my colleague Gunnar Kosche.
Identity Services Tenant Model
SAP’s Identity Authentication service is delivered with one productive and one test tenant per customer. When a customer has multiple SAP cloud products, they should all be integrated with the same Identity Authentication tenant, so that single sign-on for the business users will be established by default.
If a customer wishes - for whatever reason - to have more than those two default tenants, additional Identity Authentication tenants may be licensed via the SAP Store or the consumption-based licensing SAP BTP Enterprise Agreement (CPEA).
There are two exceptions to this default tenant model:
- SuccessFactors BizX
SuccessFactors is a natural system of origin for employee users and if a customer has more than two BizX environments, then this may lead to a need to have separate identity providers as well. For that reason, it is possible to request – via the SuccessFactors Upgrade Center – a corresponding Identity Authentication tenant per BizX instance. Such an additional Identity Authentication tenant will be granted free of charge, but its lifetime is tied to the corresponding BizX instance. - SAP cloud products licensed in different regions in the world
If a globally acting company licenses SAP cloud products in different regions in the world, there may be a (legal) need to have separate landscapes per region. In such a case a customer may request dedicated Identity Authentication default tenants for another region. Single sign-on can then not be established by default, yet personal data will be separated per region.
Identifiers
When it comes to identifiers and single sign-on with a central identity provider then we must differentiate two aspects:
- Logon alias
Identifiers that may be used by the end user for authentication. Such identifiers ought to be meaningful, easy-to-remember attributes for human beings, for example:
- Email address
- Employee ID
- Identifier based on semantics of the user’s name (e.g. surname + digit
- Federation identifier
After successful authentication, the identity provider will send an authentication response token to the service provider. The user, for whom this token is issued, is uniquely specified with the ‘subject name identifier’ attribute. This identifier, used for the communication between identity provider and business application, does not need to be human readable, but above all it ought to be unique and immutable and thus stable identifier across all times.
Examples:
- User UUID
- Immutable username
Multi-factor authentication
Protecting access to public cloud solutions with strong means of authentication is essential from a security perspective. Requesting a second factor from the users ideally happens in the corporate identity provider where employee users login to access their business applications. This will ensure ease-of-use for the end users. If the second factor is enforced by a different authenticating authority, the users will have to register in this IdP in addition to the corporate IdP.
SSO for system-to-system communication
When we talk about single sign-on, we often only refer to the use case where a user accesses an application with his browser. Yet it is also important to have scenarios in mind, where applications need to retrieve content from other applications or write entries to foundation services (e.g. a central audit log). This system-to-system communication may be established with a trust ‘on behalf’ of the applications, but then the user context gets lost. It is however often required to provide evidence which user initiated the system call. In such cases the system-to-system call ought to be protected with a security token that contains the actual user information (‘principal propagation’).
System-to-system communication with principal propagation
Reference Architecture Scenarios
Many SAP customers adopted SAP cloud products and integrated them into their system landscape. The chosen IAM approach depends on the desired integration from single sign-on perspective, whether a customer has a unified, simple IAM landscape or whether a customer has a rather complex landscape in place.
When we look at the chosen landscape patterns from single sign-on perspective, then we can distinguish several architecture scenarios. We will only consider productive landscapes and differentiate based on the number of identity provider tenants.
Sketching test landscapes is even a different story, not investigated here.
Scenario 1: Recommended IAM architecture for hybrid landscapes
In a typical ‘model’ landscape all SAP cloud applications of a customer delegate authentication to a single Identity Authentication tenant which integrates with the corporate identity provider. This will ensure on the one hand single sign-on for the employee users accessing SAP applications - and on the other hand ensure that the applications receive security tokens not only for browser-based single sign-on but also security tokens that can be leveraged for subsequent system-to-system communication.
Hybrid landscape with single Identity Authentication tenant and single corporate IdP
What are the pros and cons and what needs to be considered from IAM perspective?
Pros
- Seamless single sign-on for the end users
- Flexible authentication that allows single sign-on for employee users with corporate IdP whereas other users (e.g. partner or customer users) can authenticate in Identity Authentication
Cons
- -
Recommendations
- The federation identifier for SAP cloud applications should be chosen deliberately. As described above an immutable identifier should be passed in the authentication token to the applications. Preferred candidates are:
- Either user UUID generated in Identity Authentication
- Or an immutable unique identifier managed in the customer’s corporate IdP.
This identifier must of course be provisioned before authentication to the business applications with an identity management solution.
- Multi-factor authentication – if required - can either be enforced in the corporate identity provider or in Identity Authentication. It is recommended to enforce it in that IdP, where the users manage their first factor (e.g. password); thus for employees the second factor is ideally managed and validated in the corporate IdP.
===
This ideal landscape setup of scenario 1 cannot always be achieved or is initially not yet desired. Customers sometimes get started with an isolated landscape setup for cloud applications. Sometimes customer landscapes are fragmented and then there are some challenges to tackle in order to establish single sign-on. So we have to take additional scenarios into account and figure out what impact it has on the integration aspects.
Scenario 2: Pure cloud landscape with single Identity Authentication tenant
Some customers commence their journey to the (SAP) cloud by adopting ‘lightweight’ SAP cloud applications like SAP Innovation Management or Business Technology Platform and - in a first step - do not integrate it from IAM perspective into their corporate environment.
What are the pros and cons and what needs to be considered from IAM perspective?
Pros
- Easy to setup and administrate
- No integration effort with corporate identity provider
- Usually no (full) governance approval needed from corporate security department
Cons
- No corporate single sign-on for the end users
Recommendations
- Scenario 2 is only recommended for a trial usage phase for SAP cloud solutions
- The question of federation identifier should consider future integration with a corporate IdP.
I.e. one should either establish Identity Authentication user UUID as the central user identifier for SAP cloud applications or make sure that an already established identifier for employee users is provisioned to Identity Authentication.
This will avoid any migration efforts of user content in the business application at a later point in time when single sign-on will be established with the corporate IdP. - Multi-factor authentication can be enforced in Identity Authentication if required
Scenario 3: Hybrid landscape with single Identity Authentication tenant and SAP Single Sign-On
The Identity Authentication service is the solution of choice to establish single sign-on for browser-based access to SAP applications. Yet many customers still have SAP NetWeaver AS ABAP on-premise systems in use. Often these ABAP systems are accessed with SAP GUI – and this desktop client does not support SSO protocols like SAML or OpenID Connect. For that reason SAP Single Sign-On is commonly used to facilitate single sign-on with either X.509 certificates or Kerberos as authentication mechanism.
Scenario 3: Hybrid scenario with single Identity Authentication tenant and SAP Single Sign-On
What are the pros and cons and what needs to be considered from IAM perspective?
Pros
- End users will benefit from single sign-on to both browser-based SAP applications as well as access with desktop clients
Cons
- Additional components and authentication protocols (Kerberos or X.509) will be required
Recommendations
- Scenario 3 is recommended when SAP NetWeaver ABAP on-premise systems are involved and these systems shall be accessed with SAP GUI
- Multifactor authentication can be enforced for both scenarios in Identity Authentication or SAP Single Sign-On
Scenario 4: Hybrid landscape with single Identity Authentication tenant and multiple corporate IdPs
In case a customer does not have a single corporate identity provider to establish single sign-on for its’ corporate users, then it is still an option to set up single sign-on for SAP cloud applications with one Identity Authentication tenant. The conditional authentication configuration in Identity Authentication can be used to forward the corporate users to ‘their’ IdP for authentication.
All SAP cloud applications can trust this single Identity Authentication tenant for browser-based access and Identity Authentication can serve as the trusted entity for security tokens issued for subsequent system-to-system communication with principal propagation.
Scenario 4: Hybrid landscape with single Identity Authentication tenant and multiple corporate IdPs
What are the pros and cons and what needs to be considered from IAM perspective?
Pros
- Seamless single sign-on to SAP cloud applications for the end users
- Identity Authentication can be used to harmonize user identifiers
- Identity Authentication is the single trusted entity for SAP cloud application for both browser-based single sign-on as well as principal propagation for system-to-system communication
Cons
- The initial authentication step in Identity Authentication requires users to enter their logon alias so that Identity Authentication can forward them to ‘their’ corporate IdP.
Recommendations
- Scenario 4 is the recommended setup for customers who have a fragmented IAM on-premise landscape but want to harmonize SSO for the SAP cloud landscape
- Multi-factor authentication should be enforced in the corporate identity providers
Scenario 5: Hybrid landscape with multiple Identity Authentication tenants and single corporate IdP
Companies with a single corporate identity provider that see a need to establish multiple Identity Authentication tenants for the SAP cloud landscape is a rather rare use case, but still some customers decided to go that route. Here some examples:
- Local ‘project landscapes’ that are not integrated in corporate single sign-on where authentication is handled with a separate Identity Authentication tenant
- Regional ‘project landscapes’ that are not integrated in corporate single sign-on
- Holding/subsidiary companies where access governance shall be separated per legal entity
- Global acting companies with SAP cloud applications in different regions in the world establish ‘local’ Identity Authentication tenants to avoid latency issues for the users when logging in.
Let’s take this example to illustrate how such a landscape will look like:
Scenario 5: Hybrid landscape with multiple Identity Authentication tenants and single corporate IdP
What are the pros and cons and what needs to be considered from IAM perspective?
Pros
- Flexible setup for project specific applications or regional landscapes
- In global landscapes local Identity Authentication tenants ensure that personal data remains in one region and login to applications does not face latency issues
Cons
- Identity Authentication user UUID should not be used as federation identifier, since the user UUID will be generated in each Identity Authentication tenant
- If multi-factor authentication is required, it should be enforced in the corporate IdP.
In case of ‘project’ landscapes it can be enforced in Identity Authentication.
Recommendations
- Scenario 5 is only recommended for the described special use cases
Scenario 6: Hybrid landscape with multiple Identity Authentication tenants and multiple corporate IdPs
In case a customer has multiple corporate identity providers and in addition sees a need to establish multiple Identity Authentication tenants to protect access to his SAP cloud applications, then this will be the most challenging scenario from single sign-on perspective.
Scenario 6: Hybrid landscape with multiple Identity Authentication tenants and multiple corporate IdPs
What are the pros and cons and what needs to be considered from IAM perspective?
Pros
- Scenario 6 does not really show any ‘pros’, it’s just a fact that a lot of customers have to cope with rather complex landscapes. And the good news is, that SAP offers solution options for such difficult environments.
Cons
- It will be a challenge to ensure single sign-on for all users and all application accesses
- Identity Authentication user UUID should not be used as federation identifier, since the user UUID will be generated in each Identity Authentication tenant
- If multi-factor authentication is required, it will probably not be easy to decide where to enforce it
Recommendations
- Scenario 6 is not really recommended, it’s rather that one has to deal with it in a given landscape setup
Conclusion
SAP’s strategy to enable single sign-on for all its’ cloud solutions is to establish the Identity Authentication service as a central component that provides browser based single sign-on, token service for principal propagation, various options for multi-factor authentication and harmonization capabilities for user identifiers. Identity Authentication is a key element for SAP to deliver an integrated, microservice based cloud portfolio.
Ideally customers establish one single Identity Authentication tenant that serves as identity provider for all their SAP cloud solutions.
References
SAP Integration Strategy Community Topic Page
CIO Guide: Identity Lifecycle in Hybrid Landscapes
Identity Lifecycle: SAP Reference Architecture for Identity Access Management
Secure Operations Map
SAP Cloud Identity Services community
Evolving IAS and IPS into SAP Cloud Identity Services
- SAP Managed Tags:
12 Comments
