SAP IAS in proxy mode and its coexistence with Azure Active Directory

Cloud Security Carsten Olt

Our introductory blog for the SAP Cloud Platform Identity Authentication Service (IAS) offered an overview of the different options for integrating SAP IAS, its user management, and its various authentication options.

Over the course of this blog series, our goal is to demonstrate that the IAS is an incredibly powerful and flexible service that offers a wide array of interesting features and integration options. We’ll also explain why – thanks to its open interfaces, modern standards and frequent feature updates – SAP IAS is far superior to most existing (and often outdated) identity providers on the market. 

And if you decide that you still want to continue using your existing authentication processes and identity provider (IdP), we’ll show you how you can operate the SAP IAS as an identity provider proxy.

In this post, we’ll use a typical customer scenario to show you how SAP IAS can be optimally integrated, using the example of Microsoft Azure Active Directory as an identity provider and the cloud solution SAP Ariba as a service provider.

Why Authentication Is a Company-Wide Concern

Secure authentication and single sign-on are topics that should be taken into account across all applications within an organization. Most security professionals acting within this environment know that the modern authentication process extends beyond a company’s network perimeter and should include user and device identity. 

Organizations can use “identity signals” as part of their access control decisions. Today, companies should create clear guidelines regarding the authentication processes, especially if the boundaries between the intranet and cloud are becoming increasingly blurred. 

These requirements should also include the SAP landscape and SAP applications in the cloud.

Conceptual Conditional Access process flow
Figure 1 | (Source: Microsoft)

Conditional Access 

Conditional access is the tool that Azure Active Directory uses to bring together such signals, make decisions, and enforce organizational policies. Guidelines for conditional access are enforced after completion of the so-called first-factor authentication, which is usually a successful login. Conditional access is therefore at the heart of the identity-driven control level.

Such guidelines are basically simple “if-then” instructions. If a user wants to access a resource, he or she has to fulfill certain conditions that relate to the device, the IP geolocation, the user or their group memberships, the target application, and other factors. The actual access decision, or the need for additional authentication (MFA), is then made on the basis of this check.

Companies are now faced with integrating secure access to a growing number of SAP applications (on-premise or cloud) in their conditional access policies. One thing is clear: this is only possible if all teams work together. Driven solely from the SAP basis, introducing secure authentication for SAP will not lead to success. In our projects, we often see that silo solutions have been set up because a company’s cloud security strategy does not take into account the SAP landscape. IT security knows nothing about SAP security, and vice versa.

SAP has integrated IAS as a preconfigured default IdP in many SAP cloud solutions, which reduces the effort and complexity required to set up every single application for SAML authentication.  More reasons for this integration can be found in our overview blog. Consequently, this means customers are no longer able to set up a direct trust to their existing IdP, like Azure Active Directory.

Introducing another IdP with the onboarding of new SAP cloud applications may confuse some IT security experts. In the next section, we will cover the integration of SAP IAS as an Identity Provider proxy. This enables very powerful and flexible integration scenarios, and it is necessary to understand which synergies result from the parallel operation of both solutions.

Integration of SAP IAS as IdP-Proxy in Microsoft Azure

Let’s say you would like to use Microsoft Azure Active Directory as your primary corporate identity provider to authenticate all users. If so, all known security functions — such as conditional access and MFA — can continue to be used for SAP (cloud) applications as well.

It is important to understand that from the perspective of Microsoft Azure Active Directory, SAP IAS is just another service provider. In typical customer scenarios, a large number of service providers (so-called enterprise applications) continue to be connected directly with Azure, while the SAP IAS is used as a central hub and proxy system for the connected SAP applications.

A parallel operation then looks something like this:

Figure 2 | (Source: Xiting)

The integration of the SAP Identity Authentication Service means simplification and centralization. The administration of the various SAP applications can thus be decoupled from IT security, while the existing authentication guidelines and methods are retained. 

The operators of the Corporate IdP (in this case, Azure) do not have to integrate each SAP application individually. They do not have to constantly exchange metadata with the SAP security admins when introducing a new application or discussing the correct SAML claims required by the application.

Let’s take a look at how SAP IAS works in proxy mode, and what that means. 

The following participants are involved in such a proxy relationship:

Corporate IdPIdPBMicrosoft Azure Active Directory
(any other SAML IdP is possible)
Proxy IdPIdPASPBSAP Cloud Platform Identity Authentication
Service ProviderSPASAP Ariba or SAP IBP
(any other SAML-compatible application is possible) 

And this scenario looks something like this:

Figure 3 | (Source: Xiting)

In this setup, the corporate IdP (in this example, Azure) is used for authentication, while the SAP Identity Authentication Service acts as a proxy to delegate authentication to the external corporate IdP. 

SAP IAS is, therefore, SAML IdP for the SAP applications (in this example, SAP Ariba). At the same time, it functions as a service provider for your corporate identity provider.

If a user, such as an employee who is present in Azure, tries to access SAP Ariba, SAP IAS redirects them to Azure. The user must then authenticate, which in turn includes the known methods including conditional access, MFA and others.

In this so-called service-provider-initiated authentication process, the client browser is sent several times from A to B, and has the task of forwarding the different authentication requests and responses to the right place. 

Since the SAML 2.0 specification allows such operation, this cascading is nothing unusual — and you could even add additional systems to the scenario.

The SAML authentication process (Figure 3) explained in 14 steps:

  1. A browser client requests a web resource protected by a SAML SP (SPA). In this example, that’s SAP Ariba. If a security context for the principal already exists at SPA, go to Step 14.
  2. The client is redirected to the IdP component of the SAP IAS, acting as the IdP Proxy (IdPA), which is protected by the SP component of IdP Proxy (SPB).
  3. The client makes a SAML AuthnRequest to the SSO service at IdPA. If a security context for the principal already exists at IdPA, go to Step 10 – this behavior can be configured.
  4. The AuthnRequest is cached, and the client is redirected to the authenticating IdP (IdPB), which is the Corporate IdP (Azure Active Directory, in this example).
  5. The client makes a SAML AuthnRequest to the SSO service at IdPB. If a security context for the principal does not exist, IdPB identifies the principal (details omitted).
  6. IdPB updates its security context for this principal, issues the assertion, and returns the SAML AuthnResponse to the client.
  7. The client submits the response to the assertion consumer service at the SAP IAS (SPB), which validates the assertion in the response.
  8. SPB updates its security context for this principal and redirects the client to IdPA.
  9. The client makes a SAML AuthnRequest to IdPA, the same AuthnRequest made at Step 3.
  10. IdPA updates its security context for this principal, issues a single assertion, and returns a response to the client. The response may also contain the claims issued by the Corporate IdP (IdPB) at Step 6, or additional claims from the SAP IAS.
  11. The client submits the response to the assertion consumer service at SPA, which validates the assertion in the response.
  12. SPA updates its security context for this principal and redirects the client to the resource.
  13. The client requests the resource (the same request issued at Step 1).
  14. The resource makes an access control decision based on the security context for this principal and its claims provided in the SAML AuthnResponse and returns the resource to the client.

It is important to understand that the (Azure) users do not need a profile (account) in the IAS user store if it is operated in proxy mode. However, this is recommended for many cases, especially if there are various requirements towards customizing SAML claims sent to the application. 

Adjustment of the SAML Claims (Modify, Enrich or Replace)

Every cloud application (service provider) has its own characteristics concerning user management and the requested SAML Name Identifier (NameID) formats and attributes. This directly affects the so-called user mapping you need to take care of after the successful authentication process. Ultimately, an attribute from the SAML assertion that the IdP issues is used for authentication.

In the illustrated proxy scenario, the SAP Identity Authentication Service was added as an enterprise application within the Azure Active Directory. After exchanging the metadata on both sides, it was determined, for example, that Azure passes the email address as a SAML NameID with the format urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress and a few other desired claims (possibly group memberships or UIDs). 

In the configuration of SAP IAS, the corporate IdP is activated for the respective application and thus the authentication is delegated to the Azure Services.

In this scenario, SAP IAS is always the issuer of the SAML assertion for the respective (SAP) target application, but depending on the configuration, it can either pass on the claims defined from the corporate IdP or additional ones from the IAS user store. 

These claims are forwarded either directly to the target system (for example, SAP Ariba), or the SAML assertion is enriched with additional attributes such as SAP user ID or group memberships, which may not be provided by the corporate IdP. In some applications, such as the SAP Cloud Platform, authorization is controlled using group-to-role assignments from the SAML assertion. This allows the IAS admin to implement an independent group concept within SAP IAS.

An IAS administrator can modify or enrich the assertion attributes received from the corporate identity provider before they are sent to the application (service provider) that uses the corporate IdP for authentication. SAP IAS can also override the assertion attributes from the corporate identity provider and instead provide attribute values such as group assignments that are maintained in the IAS console or provisioned by an IDM system using SCIM.

Let’s use SAP Ariba as a first example. Here, the user IDs for authentication are always treated as “case-sensitive,” which is also described in SAP Note 2461598. This often leads to authentication issues, usually if the user has been created in (Azure) Active Directory with a different spelling (mixed case). Therefore, it is typically recommended to use the email address (though this is not always possible).

Example: The administrator of the IAS tenant can use a function to convert the NameID received from the corporate IdP into upper or lower case letters, depending on the application. This can usually solve this typical Ariba issue.

Identity Federation

The administrator of the IAS tenant can determine whether the attributes from the SAML assertion of the corporate IdP or the IAS user store should be used. Access can be restricted based on the user profile, or additional risk-based authentication policies can be applied and enforced at the IAS level.

You can also check if the users authenticated by the corporate identity provider exist in the SAP IAS. For users that exist, data from the IAS user store is taken and the NameID, assertion and default attributes according to the application configuration are sent. For users with no profile in SAP IAS, the application receives the NameID attribute from the corporate IdP assertion, and the attributes according to the application configuration.

To make use of the Identity Federation features, additional configurations at the SAP IAS tenant must be made so that the changed attributes are taken into account. Furthermore, companies need a method for user provisioning, such as SCIM REST APIs. This way, the profiles can be generated automatically in SAP IAS. The use of other SAP solutions — such as SAP IDM 8.0 in conjunction with the SAP Cloud Platform Identity Provisioning Service — can also be helpful.

Example: The assertion attributes received from the corporate IdP should be changed before they are sent to the application. Prefixes or suffixes can be added or special attributes (Application Custom Attributes) can be used. This works for both SAML 2.0 and OpenID Connect (id_token) applications. So instead of the email address of the Azure user (for example), the SAP User ID can be sent as NameID with the format unspecified to the SAP cloud application, or additional group memberships if the application requires it.

Thanks to these features, the illustrated proxy scenario could be expanded:

  1. to authenticate employees who have also been provisioned in the SAP IAS to the target application with different or enriched SAML claims.
  1. to authenticate external users, such as partners and customers, directly at the IAS without being known in Azure (IDP-initiated authentication via a special URL; this way, the Azure login can be bypassed for certain users despite the corporate IdP being activated).
Ein Bild, das Screenshot, Straße enthält. Automatisch generierte Beschreibung
Figure 4 | (Source: SAP SE)

Conclusion

Organizations can still use an existing SAML identity provider to authenticate all employees to the various SAP (cloud) applications, while taking existing security requirements into account, despite the use of the SAP Cloud Platform Identity Authentication Service. 

If there is no existing corporate IdP available, the SAP IAS can take over its role completely, operating as a central identity provider for both cloud and on-premise SAP and non-SAP applications.

Finally, the benefits of Identity Authentication Service in proxy mode…

Central SSO endpoint for all SAP cloud applications:

  • Single trust configuration to customer’s corporate identity provider
  • Easy to set up for customers
  • Pre-configured or semi-automated trust configuration for SAP cloud applications
  • Choice between SAML and OpenID Connect, including protocol conversion towards SAP applications
  • One SSO session for all SAP cloud applications, with the option to enforce separate access control policies 
  • Single audit log for authentication
  • SSO for all SAP cloud applications

Extended configuration and security settings:

  • Service-provider-specific attribute mapping/rewriting and assertion enrichment, without the need to adjust the corporate identity provider
  • Easy separation mechanism for multiple user stores (internal, external, and employees)
  • Flexibility to configure where user credentials are validated.
  • Risk-based authentication with the option to enforce stronger means of authentication

Xiting supports organizations integrating a company-wide strategy for secure authentication into the SAP environment and acts as an intermediary between the worlds of IT security and SAP security.

In our work, we continuously incorporate actual project experiences with our customers. For this reason, we would like to point out a limitation in this proxy scenario in conjunction with IAS and Azure Conditional Access. From the Azure perspective (corporate IdP), SAP Identity Authentication is a “black box” where all applications behind it are practically masked. In many cases, this isn’t an issue. However, if there are special requirements, at the moment there is no solution available either from Microsoft Azure AD or SAP.

Currently (Oct 2020), it seems technically impossible to configure individual IAS applications with different Azure Conditional Access policies, e. g. to check for company-managed devices and allow access to particular IAS applications based on the device status. We will keep you updated here as well as on the SAP Community for SSO and Security.

Further information here.

Carsten Olt
Latest posts by Carsten Olt (see all)
Contact

Get in touch with us!

Do you have questions about our products?

+41 43 422 8803
[email protected]
+49 7656 8999 002
[email protected]
+1 855 594 84 64
[email protected]
+44 1454 838 785
[email protected]
Contact
Webinars

Attend our live webinars and learn more from our experts about SAP authorizations, XAMS, SAP IDM and many other topics in the context of SAP security.

Register now