In this blog we cover some basics, explain the functionality, and use cases of the most relevant standards like SAML 2.0, OAuth 2.0, and OpenID Connect. In addition, we provide you with a configuration guideline that provides a deeper insight and supports your identity federation setup between your SAP IAS and Azure tenants.
UPDATE: E-Book for this blog is now available for download
It contains all information from this blog as well as the configuration part and deals with the integration of SAP Identity Authentication Service with your Azure Tenant.
Most of the implementations with corporate IDPs we have done so far were based on the SAML 2.0 standard. In the Q2 2022 roadmap, you can find the information that SAP IAS now supports federation with a corporate identity provider using OpenID Connect. As of September 2022, this support is limited to Microsoft Azure Active Directory. In this scenario, IAS uses the Azure OpenID Connect identity provider as an external authenticating authority. IAS thus acts as a proxy to delegate authentication to the external IDP.
This blog is for those of you who struggle with configuring your SAP IAS tenant as a proxy to forward authentication requests to your Azure AD tenant using OpenID Connect.
In our opinion, configuring this scenario currently isn't sufficiently documented in SAP Help as of September 2022, to put it mildly. Sorry SAP, but we only received the necessary information through the OSS and your support, this could go better.
For this reason, we like to share our experience with the community and look forward to further discussions on this topic. I'm happy to exchange views on the benefits of connecting IAS to the corporate IDP via ODIC rather than SAML.
Even if you are familiar with SAML 2.0 you may have noticed, OIDC works differently. It supports different authentication flows and the terminology used for the involved entities is different as well. In short, to really understand and implement OpenID Connect, we recommend trying to first understand the underlying OAuth 2.0 framework. OIDC operates on top of it.
Furthermore, OIDC is considered SAP's preferred standard for the SAP BTP and undoubtedly future SaaS applications. SAP BTP in combination with SAP Cloud Identity Services, automates the creation of OpenID Connect (OIDC) applications with the customers' IAS tenant(s). Therefore, soon more and more SAP organizations will have points of contact with this standard… have fun reading!
Introduction
Benefits of using IAS in proxy mode
Adjustment of claims (modify, enrich or replace)
Identity Federation
Conclusion
Benefits of OIDC compared with SAML
What is Security Assertion Markup Language (SAML) 2.0
What is OAuth 2.0
What is OpenID Connect (OIDC) 1.0
How are OIDC and SAML connected
Conclusion
Configuration guideline
Obtaining required information from your Azure tenant
Setup the OpenID Connect IDP in IAS
Register IAS as an application in your Azure tenant
Finish and validate the OpenID Connect IDP configuration in IAS
Obtaining an ID token from your Azure tenant using Postman
To simplify access, organizations typically want to reuse their existing IDP. Often these are Azure AD, ADFS, Nevis Identity Suite, Okta, Ping Identity, and other SAML and/or OIDC-compliant IDPs that one may like to integrate with.
IAS delegates authentication to the external IDP and functions as a proxy for another IDP. An IDP proxy allows the creation of trust relationships that simplify the management of the many SAP applications (cloud and on-premises). The reason for this is simple: this IDP often is connected with your corporate user base, knows all identities, handles their login credentials, and offers additional SSO and security capabilities such as MFA.
With the FIDO2 support, we observe tendencies indicating increased use of passwordless authentication. IAS allows integration with third-party solutions in flexible ways. Those may be used to guarantee the highest level of privacy and security including features like identity verification. Such solutions like the Nevis authentication cloud can cover different B2C, B2B, and B2G use cases with significantly higher security and a broader range of capabilities. Think about scenarios geared towards customers and external partners, developers, and others.
The well-known combination of SAP IAS and MSFT Azure AD unites conditional authentication and MDM policies like restricting access to company-managed devices only with additional security features from SAP IAS or third parties.
SAP Cloud Identity Authentication (IAS) acting as a proxy, can use a SAML 2.0 or an OpenID Connect identity provider as an external authenticating authority for the application. The choice depends on your scenario and needs. For SAP BTP and mobile applications, the recommended protocol is OpenID Connect. On the other hand, if in your scenario IAS acts as a proxy to multiple identity providers, and you allow the partner users to log in via their corporate identity providers, the choice could be SAML 2.0.
In one of our older blogs, we already wrote about using IAS acting as a proxy to delegate authentication requests to existing (and even multiple) corporate identity providers. To obtain some basic understanding of the proxy scenario we recommend reading this blog first.
From an authentication perspective, in short here is what happens:
It is important to understand that from the perspective of the corporate IDP, the IAS is just another service provider (SP). In typical customer scenarios, a large number of service providers continue to be connected directly with the corporate IDP, while the IAS is used as a central hub and proxy system for the connected SAP applications.
Every cloud application has its characteristics concerning user management and the requested Name Identifier formats and attributes. This affects the user mapping that you need to take care of after the successful authentication process. 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).
The corporate IDP is activated for the respective application(s) in IAS, which always is the issuer of the SAML assertion for the respective (SAP) target application. However, depending on the configuration, it can either pass on the claims defined by the corporate IDP or additional ones from the IAS user store.
Furthermore, IAS supports RegEx filters and various modifications and transformations for the assertion attributes received from the corporate identity provider before they are sent to the application. IAS can override the assertion attributes from the corporate IDP and instead provide attributes, claims, and group assignments that are maintained in the IAS console or provisioned by an IDM system using SCIM.
ID-Federation by definition provides the means to share identity information across company boundaries. A User must be unambiguous and clearly identifiable, even though different user identifiers may exist across the landscape. The name identifier (name ID) is the means to establish a common identifier and once established, the user is said to have a federated identity.
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 to every single application can be restricted based on the user profile, or additional risk-based authentication policies which can be applied and enforced in addition.
You may also want to 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 to implement automated user provisioning. 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 Identity Provisioning is helpful to manage the user lifecycle.
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 IAS Login Name can be sent as NameID with the format unspecified to the SAP cloud application.
Thanks to these features, the proxy scenario can be expanded to authenticate employees who have also been provisioned in the SAP IAS to the target application with different or enriched SAML claims. Also 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).
Finally, this proxy integration allows using Identity Federation/Propagation between the corporate identity provider and the IAS. To support this, IdDS provides an extendable user store with a set of SCIM APIs that aim to simplify user management and persistence. With this, the concept of the universally unique identifier (UUID) has been introduced at the end of 2020 where IAS is the instance that generates and owns it.
This is what makes IAS so powerful and flexible and why SAP recommends persisting users to IAS. To obtain further information about the IdDS you can read this nice blog from Sonia Petrescu.
It became clear that SAP Cloud Identity Services with its capabilities of secure authentication, identity federation, SSO, and SCIM-based identity provisioning are a core element in SAP BTP. Consequently, many customers are connecting the Identity Services as a proxy to their corporate IDP to reuse existing processes for authentication, SSO, or MFA. This way they decide if the user identifiers and claims are just forwarded as received from the corporate IDP or managed through the IAS utilizing its user persistence and group management interfaces. This way, customers control the authorization independently allowing for separation of Azure and SAP security administration teams. Lastly, there are interfaces allowing to automate everything using APIs through an existing IAM solution.
Two of the main authentication protocols in the cloud world nowadays are:
Key aspects of both are asserting a user's identity, providing standardized mechanisms and protocols, different authentication flows, and finally trust. Both provide a cross-domain and cross-vendor single sign-on (SSO) standard.
SAML is the most flexible and adopted SSO technology supporting both on-premises and cloud applications. It is an XML-based authentication framework that is specified primarily for browser-based access. It uses a dynamic token model that works based on assertions. Here both the authenticating instance and the application server can be operated externally, supporting more flexible user federation scenarios beyond the B2E use case.
SAML-enabled web applications delegate user authentication to a central instance. The identity provider proves that a subject (user) has identified himself. Users authenticate to the IDP by different means, which may involve various supported SSO methods or additional authentication factors. A successful authentication triggers the creation of a SAML assertion that certifies a user's identity against the target application, termed the SAML service provider (SP). IDP and SP must establish a mutual relationship of trust beforehand. That involves the exchange of so-called SAML metadata on both sides containing the Entity IDs, protocol endpoints, supported bindings and attribute formats, and required cryptographic keys.
A SAML assertion enables SSO during the lifetime of the browser session. It is accepted as proof of identity by web applications. The assertion definition is very flexible and enables an easy mapping of attributes between systems for loosely coupled integration across organizations. Browser applications on desktop and mobile devices support the SAML authentication flow.
SAML 2.0 is a very secure and powerful framework based on X(AC)ML, X.509, and digital signatures and albeit older, still a good choice for various authentication and authorization scenarios. No surprise SAML is not designed for the requirements of modern mobile apps, after all this standard existed even before I held the first iPhone 2g in my hands 🙂
The simple fact that SAML is older compared to OIDC, doesn't necessarily mean it's no longer valid or insecure. Recently a former security colleague and namesake of mine impressively reminded me of the good old client-certificate-based TLS authentication (CBA). Many are dealing with phishing-resistant MFA right now, while CBA has been resistant to monster-in-the-middle attacks since a time when no one paid attention to gender neutrality and you could call it man-in-the-middle - it was 1999. Pay attention to rfc2246 "CertificateVerify": The client must sign the previous session including the server certificate. This ensures security even if the client trusts an incorrect CA certificate. (Thanks Carsten)
To learn more about secure authentication for SAP and SAML, you can read the OASIS SAML 2.0 technical overview and one of our previous blogs
Plenty of other blogs about SSO and SAP cloud security can be found here
OAuth 2.0 (RFC 6749) is seen as a complete redesign and not compatible with the deprecated OAuth 1.0 standard. OAuth still is an authorization framework that solves the problem of delegated access without credential sharing, is a protocol for delegating authorizations, and is not suitable for authentication.
It aims to simplify authorization for developers as it offers specific authorization processes - called flows - suitable for different application use cases and so-called Authorization Grant types. To request access to an OAuth-protected resource (API), the OAuth client obtains authorization from the resource owner - with this permission, the client then requests an access token.
OAuth 2.0 has established itself as the standard for securing API access. Since the OAuth process (obtaining access token) is usually required in combination with user authentication, it made sense to use OAuth for the login as well - this is where OpenID Connect comes into play.
Check out this great blog from rajaprasad.gupta for more details about OAuth and JWT.
OpenID Connect 1.0 was adopted as a standard in February 2014 and should not be confused with the outdated OpenID 2.0 standard.
Put simply, OAuth 2.0 is a protocol and - with OpenID Connect 1.0 as an extension - a login method that confirms user identities based on an existing, verified authentication (ID token) and authorizes them by using access tokens.
An OAuth client can request the OpenID extension by adding the scope "openid" to an authorization request. Information about the identity of the user and the authentication performed is returned to the client in an additional (OpenID-specific) token, the so-called ID token. The standard defines the ID token must be in the JWT format and is restricted to a specific client. Additionally, the UserInfo endpoint was introduced, seen as another OAuth-protected API for accessing user data.
Any OAuth 2.0 authorization server that supports OIDC is also known as an OpenID Provider (OP). Accordingly, every OAuth 2.0 client that uses OpenID Connect is called a Relying Party (RP).
“OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.” (https://openid.net/connect/)
“The Security Assertion Markup Language (SAML) is an XML-based federation technology used in many enterprises and academic use cases. OpenID Connect can satisfy these same use cases but with a simpler, JSON/REST-based protocol. OpenID Connect was designed to also support native apps and mobile applications, whereas SAML was designed only for Web-based applications.” (https://openid.net/connect/faq/)
The three aspects of login, authentication and authorization can be realized using OAuth, JWT and OpenID Connect. As an extension to OAuth 2.0 it represents a functional and secure authentication system.
The main driver for a protocol is the client usage and with SAP cloud (BTP & SaaS) and especially with mobile applications the use of OAuth 2.0 and OIDC has gained stronger importance. IAS supports a mix of both standards. However, mixing always makes the configuration more complicated. Therefore if a corporate IDP supports OIDC and the client uses it, the complete authentication flow is much leaner compared to SAML2/OIDC in combination.
You can follow this documentation on help.sap.com. However, the v1 endpoint is still being used there. According to SAP they experienced unexpected behavior and suggested using the v2 endpoint. This information is currently not included in the documentation, for this reason, we suggest following the steps outlined here.
In this example, we use our demo environment with some sandbox systems (nothing secret, so we won’t obfuscate those values here)
Azure Tenant ID: bbffd6ff-54e5-498a-8632-2b05586ee6f9
IAS Tenant: ias.carstenolt.de
First, obtain the metadata from your Azure AD tenant. OpenID Connect describes a metadata document that contains most of the information required for an app to perform a login. For this, the OP typically publishes its metadata at a well-known URL. To query your discovery or well-known endpoint - use this URL: https://login.microsoftonline.com/<azure-tenant>/v2.0/.well-known/openid-configuration
Result:
On your IAS tenant switch to Identity Providers → Corporate identity providers
and create a new entry - for example: OIDC_IDP
Switch Identity Provider Type to OpenID Connect Compliant:
Now Switch to OpenID Connect configuration and enter the URL: https://login.microsoftonline.com/<azure-tenant>/v2.0/.well-known/openid-configuration
in the field Discovery URL. Press Load, and IAS will populate the Issuer URL from the metadata.
The issuer in this case is: https://login.microsoftonline.com/<azure-tenant>/v2.0
Now we see that we need to enter a Client ID and secret to authorize and validate our OIDC client connection. For this reason, now it’s time to switch to your Azure tenant as we first need to perform some steps there.
We will proceed here later on!
In your Azure Portal switch to Azure Active Directory → App registrations.
Add a new registration. Enter a name representing your IAS tenant and choose the supported account types according to your needs. In our scenario, we will just use a single tenant:
After a user successfully authorizes an application, the authorization server will redirect the user back to the application. Hence, we need to add a Redirect URI from type Web with the value: https://<ias-tenant>/oauth2/callback
Azure already created the OAuth 2.0 Client ID for you, in this case 0b35d68a-8420-4b92-952e-67bf1b429978…which is one of the values you will require to finish the configuration on the IAS side:
In the next step add a secret to your Azure app via Add a certificate or secret → New client secret and configure the lifetime according to your policy (ask your Azure experts for advice):
The next screen will show you the new client secret, you need to copy the value of the client secret in your password safe. Please note those values cannot be viewed again, except for immediately after creation. You don't need the Secret ID.
In this case the value is: ~4y8Q*****************************ql which is the second information you will require to finish the configuration on the IAS side.
Summary
Client ID: 0b35d68a-8420-4b92-952e-67bf1b429978
Client Secret: ~4y8Q*****************************ql
Before you finish the configuration on your IAS tenant set up some additional stuff. In the next step, we want to provide the email address of the Azure user to the ID token (JWT) issued from Azure. In addition, we want to provide the groups claim to forward the sAMAccountName of all groups the user is assigned to.
Switch to Token configuration and add email as an optional claim to your ID token (While adding this claim your API permissions may be updated).
In the same way, add the groups claim, and the final result will look like this:
Please note: Your configuration and required claims may vary depending on your environment and requirements, this is just a sample configuration (!)
Since the app registration, the creation of client credentials, and custom settings have been done on the Azure side, we are ready to finish our configuration on the IAS side.
Back in your ODIC IDP configuration, enter Client ID and Client Secret and Validate the configuration. This will execute a client credential token request to your Azure IDP to verify the credentials:
You can have up to 20 scopes. The openid scope is added by default. Each scope can have a length of up to 99 characters.
For the client credentials flow to work, Azure requires some specific scopes. In our scenario we need to add the scope <azure-client-id></.default> to our configuration:
Update 09-11-22: adding the scope "<azure client id>/.default" in section "Finish the OpenID Connect IDP configuration in IAS" is not required any more for the validate feature (thanks Torsten)
Once added, let’s try again:
In our scenario, the user identifier should be obtained from the claim email contained in the received ID token. We defined not to use the sub but instead the email claim that should be used as the subject name identifier for this Corporate Identity Provider:
Technically you can send any attribute, here we just added the email scope, so Azure puts the email address into the “email" claim. In IAS we ensure the "Subject Name Identifier" for the Corporate IdP is "E-Mail" as well, so the user is successfully federated with the user object in the IAS IdDS.
Keep in mind your configuration may vary.
As a prerequisite, you must have enabled the Use Identity Authentication user store for this to work. Of course, we enabled Identity Federation in order to make use of the entire spectrum and flexibility of the IAS:
In addition, we recommend configuring your OpenID Connect IDP name similar to your custom domain from the very beginning (in case you have one in use):
Heureka! Time to test your setup
In fact, the federation between IAS and Azure uses the OAuth grant-type authorization code. This means that no ID token can be found in your browser by using common tracer tools.
If you are as curious as I am, you can get an ID token directly from your Azure tenant, to see what information is contained there and whether the claims are delivered correctly. There are many ways, here is a simple one using a POST request to the OAuth 2.0 token endpoint (v2) of your Azure tenant via Postman:
As a result, you will receive your “id_token” and you can decode it using jwt.io
Example ID Token:
The payload contains some important information like the issuer, the intended audience (aud) which is the IAS client ID as well as the claims email and groups.
Fine, this way you can use the E-Mail claim (email) as subject name identifier for authentication and the groups for authorization purposes.
In a recent project, we had the requirement to mix some groups from the corporate IDP with group claims from IAS. Even with OIDC, this is possible using the Default Attributes.
For example, to enrich the final SAML assertion that will be sent to the application with Azure groups that start with XIT_:
Finally, configure your new OIDC Corporate Identity Provider for your IAS applications (Conditional Authentication)
This article only deals with IAS using OIDC for the Corporate IDP. Depending on your scenario, IAS supports various flows and capabilities, you can read more about them here
We hope this blog was helpful!
UPDATE: E-Book for this blog is now available for download
It contains all information from this blog as well as the configuration part and deals with the integration of SAP Identity Authentication Service with your Azure Tenant.
Most of the implementations with corporate IDPs we have done so far were based on the SAML 2.0 standard. In the Q2 2022 roadmap, you can find the information that SAP IAS now supports federation with a corporate identity provider using OpenID Connect. As of September 2022, this support is limited to Microsoft Azure Active Directory. In this scenario, IAS uses the Azure OpenID Connect identity provider as an external authenticating authority. IAS thus acts as a proxy to delegate authentication to the external IDP.
This blog is for those of you who struggle with configuring your SAP IAS tenant as a proxy to forward authentication requests to your Azure AD tenant using OpenID Connect.
In our opinion, configuring this scenario currently isn't sufficiently documented in SAP Help as of September 2022, to put it mildly. Sorry SAP, but we only received the necessary information through the OSS and your support, this could go better.
For this reason, we like to share our experience with the community and look forward to further discussions on this topic. I'm happy to exchange views on the benefits of connecting IAS to the corporate IDP via ODIC rather than SAML.
Even if you are familiar with SAML 2.0 you may have noticed, OIDC works differently. It supports different authentication flows and the terminology used for the involved entities is different as well. In short, to really understand and implement OpenID Connect, we recommend trying to first understand the underlying OAuth 2.0 framework. OIDC operates on top of it.
Furthermore, OIDC is considered SAP's preferred standard for the SAP BTP and undoubtedly future SaaS applications. SAP BTP in combination with SAP Cloud Identity Services, automates the creation of OpenID Connect (OIDC) applications with the customers' IAS tenant(s). Therefore, soon more and more SAP organizations will have points of contact with this standard… have fun reading!
TOC
Introduction
Benefits of using IAS in proxy mode
Adjustment of claims (modify, enrich or replace)
Identity Federation
Conclusion
Benefits of OIDC compared with SAML
What is Security Assertion Markup Language (SAML) 2.0
What is OAuth 2.0
What is OpenID Connect (OIDC) 1.0
How are OIDC and SAML connected
Conclusion
Configuration guideline
Obtaining required information from your Azure tenant
Setup the OpenID Connect IDP in IAS
Register IAS as an application in your Azure tenant
Finish and validate the OpenID Connect IDP configuration in IAS
Obtaining an ID token from your Azure tenant using Postman
Introduction
To simplify access, organizations typically want to reuse their existing IDP. Often these are Azure AD, ADFS, Nevis Identity Suite, Okta, Ping Identity, and other SAML and/or OIDC-compliant IDPs that one may like to integrate with.
IAS delegates authentication to the external IDP and functions as a proxy for another IDP. An IDP proxy allows the creation of trust relationships that simplify the management of the many SAP applications (cloud and on-premises). The reason for this is simple: this IDP often is connected with your corporate user base, knows all identities, handles their login credentials, and offers additional SSO and security capabilities such as MFA.
With the FIDO2 support, we observe tendencies indicating increased use of passwordless authentication. IAS allows integration with third-party solutions in flexible ways. Those may be used to guarantee the highest level of privacy and security including features like identity verification. Such solutions like the Nevis authentication cloud can cover different B2C, B2B, and B2G use cases with significantly higher security and a broader range of capabilities. Think about scenarios geared towards customers and external partners, developers, and others.
The well-known combination of SAP IAS and MSFT Azure AD unites conditional authentication and MDM policies like restricting access to company-managed devices only with additional security features from SAP IAS or third parties.
Benefits of using IAS in proxy mode
SAP Cloud Identity Authentication (IAS) acting as a proxy, can use a SAML 2.0 or an OpenID Connect identity provider as an external authenticating authority for the application. The choice depends on your scenario and needs. For SAP BTP and mobile applications, the recommended protocol is OpenID Connect. On the other hand, if in your scenario IAS acts as a proxy to multiple identity providers, and you allow the partner users to log in via their corporate identity providers, the choice could be SAML 2.0.
In one of our older blogs, we already wrote about using IAS acting as a proxy to delegate authentication requests to existing (and even multiple) corporate identity providers. To obtain some basic understanding of the proxy scenario we recommend reading this blog first.
From an authentication perspective, in short here is what happens:
- A user tries to access the target application and is redirected to the IDP configured in the SAP application (IAS).
- Based on conditional authentication rules (mostly email domain) or static configuration, IAS delegates the authentication to the corporate IDP (Azure).
- At this stage, user authentication is required for the first time, based on the windows credentials. In most cases, the users benefit from SSO combined with MFA.
- Using the SAML assertion (or ID token) issued from Azure AD, the user is propagated to IAS and the correct identity is determined in the IdDS (Identity Directory Service) used by IAS.
- As the IAS knows about the user's attributes and applies the configuration of the target application (SP) it issues the final SAML assertion (or ID token).
- It will contain the required identifiers like an e-mail address, an employee ID or login name, and even certain claims and groups or other custom attributes, which the target application can evaluate and use for AuthN and AuthZ.
- This configuration can be done individually for each application in IAS, including protocol conversion and enrichment or modification of claims.
It is important to understand that from the perspective of the corporate IDP, the IAS is just another service provider (SP). In typical customer scenarios, a large number of service providers continue to be connected directly with the corporate IDP, while the IAS is used as a central hub and proxy system for the connected SAP applications.
Adjustment of claims (modify, enrich or replace)
Every cloud application has its characteristics concerning user management and the requested Name Identifier formats and attributes. This affects the user mapping that you need to take care of after the successful authentication process. 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).
The corporate IDP is activated for the respective application(s) in IAS, which always is the issuer of the SAML assertion for the respective (SAP) target application. However, depending on the configuration, it can either pass on the claims defined by the corporate IDP or additional ones from the IAS user store.
Furthermore, IAS supports RegEx filters and various modifications and transformations for the assertion attributes received from the corporate identity provider before they are sent to the application. IAS can override the assertion attributes from the corporate IDP and instead provide attributes, claims, and group assignments that are maintained in the IAS console or provisioned by an IDM system using SCIM.
Identity Federation
ID-Federation by definition provides the means to share identity information across company boundaries. A User must be unambiguous and clearly identifiable, even though different user identifiers may exist across the landscape. The name identifier (name ID) is the means to establish a common identifier and once established, the user is said to have a federated identity.
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 to every single application can be restricted based on the user profile, or additional risk-based authentication policies which can be applied and enforced in addition.
You may also want to 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 to implement automated user provisioning. 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 Identity Provisioning is helpful to manage the user lifecycle.
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 IAS Login Name can be sent as NameID with the format unspecified to the SAP cloud application.
Thanks to these features, the proxy scenario can be expanded to authenticate employees who have also been provisioned in the SAP IAS to the target application with different or enriched SAML claims. Also 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).
Finally, this proxy integration allows using Identity Federation/Propagation between the corporate identity provider and the IAS. To support this, IdDS provides an extendable user store with a set of SCIM APIs that aim to simplify user management and persistence. With this, the concept of the universally unique identifier (UUID) has been introduced at the end of 2020 where IAS is the instance that generates and owns it.
This is what makes IAS so powerful and flexible and why SAP recommends persisting users to IAS. To obtain further information about the IdDS you can read this nice blog from Sonia Petrescu.
Conclusion
It became clear that SAP Cloud Identity Services with its capabilities of secure authentication, identity federation, SSO, and SCIM-based identity provisioning are a core element in SAP BTP. Consequently, many customers are connecting the Identity Services as a proxy to their corporate IDP to reuse existing processes for authentication, SSO, or MFA. This way they decide if the user identifiers and claims are just forwarded as received from the corporate IDP or managed through the IAS utilizing its user persistence and group management interfaces. This way, customers control the authorization independently allowing for separation of Azure and SAP security administration teams. Lastly, there are interfaces allowing to automate everything using APIs through an existing IAM solution.
Benefits of OIDC compared with SAML
Two of the main authentication protocols in the cloud world nowadays are:
- OpenID Connect (OIDC 1.0)
- Security Access Markup Language (SAML 2.0)
Key aspects of both are asserting a user's identity, providing standardized mechanisms and protocols, different authentication flows, and finally trust. Both provide a cross-domain and cross-vendor single sign-on (SSO) standard.
What is Security Assertion Markup Language (SAML) 2.0?
SAML is the most flexible and adopted SSO technology supporting both on-premises and cloud applications. It is an XML-based authentication framework that is specified primarily for browser-based access. It uses a dynamic token model that works based on assertions. Here both the authenticating instance and the application server can be operated externally, supporting more flexible user federation scenarios beyond the B2E use case.
SAML-enabled web applications delegate user authentication to a central instance. The identity provider proves that a subject (user) has identified himself. Users authenticate to the IDP by different means, which may involve various supported SSO methods or additional authentication factors. A successful authentication triggers the creation of a SAML assertion that certifies a user's identity against the target application, termed the SAML service provider (SP). IDP and SP must establish a mutual relationship of trust beforehand. That involves the exchange of so-called SAML metadata on both sides containing the Entity IDs, protocol endpoints, supported bindings and attribute formats, and required cryptographic keys.
A SAML assertion enables SSO during the lifetime of the browser session. It is accepted as proof of identity by web applications. The assertion definition is very flexible and enables an easy mapping of attributes between systems for loosely coupled integration across organizations. Browser applications on desktop and mobile devices support the SAML authentication flow.
SAML 2.0 is a very secure and powerful framework based on X(AC)ML, X.509, and digital signatures and albeit older, still a good choice for various authentication and authorization scenarios. No surprise SAML is not designed for the requirements of modern mobile apps, after all this standard existed even before I held the first iPhone 2g in my hands 🙂
The simple fact that SAML is older compared to OIDC, doesn't necessarily mean it's no longer valid or insecure. Recently a former security colleague and namesake of mine impressively reminded me of the good old client-certificate-based TLS authentication (CBA). Many are dealing with phishing-resistant MFA right now, while CBA has been resistant to monster-in-the-middle attacks since a time when no one paid attention to gender neutrality and you could call it man-in-the-middle - it was 1999. Pay attention to rfc2246 "CertificateVerify": The client must sign the previous session including the server certificate. This ensures security even if the client trusts an incorrect CA certificate. (Thanks Carsten)
To learn more about secure authentication for SAP and SAML, you can read the OASIS SAML 2.0 technical overview and one of our previous blogs
Plenty of other blogs about SSO and SAP cloud security can be found here
What is OAuth 2.0?
OAuth 2.0 (RFC 6749) is seen as a complete redesign and not compatible with the deprecated OAuth 1.0 standard. OAuth still is an authorization framework that solves the problem of delegated access without credential sharing, is a protocol for delegating authorizations, and is not suitable for authentication.
It aims to simplify authorization for developers as it offers specific authorization processes - called flows - suitable for different application use cases and so-called Authorization Grant types. To request access to an OAuth-protected resource (API), the OAuth client obtains authorization from the resource owner - with this permission, the client then requests an access token.
OAuth 2.0 has established itself as the standard for securing API access. Since the OAuth process (obtaining access token) is usually required in combination with user authentication, it made sense to use OAuth for the login as well - this is where OpenID Connect comes into play.
Check out this great blog from rajaprasad.gupta for more details about OAuth and JWT.
What is OpenID Connect (OIDC) 1.0?
OpenID Connect 1.0 was adopted as a standard in February 2014 and should not be confused with the outdated OpenID 2.0 standard.
Put simply, OAuth 2.0 is a protocol and - with OpenID Connect 1.0 as an extension - a login method that confirms user identities based on an existing, verified authentication (ID token) and authorizes them by using access tokens.
An OAuth client can request the OpenID extension by adding the scope "openid" to an authorization request. Information about the identity of the user and the authentication performed is returned to the client in an additional (OpenID-specific) token, the so-called ID token. The standard defines the ID token must be in the JWT format and is restricted to a specific client. Additionally, the UserInfo endpoint was introduced, seen as another OAuth-protected API for accessing user data.
Any OAuth 2.0 authorization server that supports OIDC is also known as an OpenID Provider (OP). Accordingly, every OAuth 2.0 client that uses OpenID Connect is called a Relying Party (RP).
“OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.” (https://openid.net/connect/)
How are OIDC and SAML connected?
“The Security Assertion Markup Language (SAML) is an XML-based federation technology used in many enterprises and academic use cases. OpenID Connect can satisfy these same use cases but with a simpler, JSON/REST-based protocol. OpenID Connect was designed to also support native apps and mobile applications, whereas SAML was designed only for Web-based applications.” (https://openid.net/connect/faq/)
Conclusion
The three aspects of login, authentication and authorization can be realized using OAuth, JWT and OpenID Connect. As an extension to OAuth 2.0 it represents a functional and secure authentication system.
The main driver for a protocol is the client usage and with SAP cloud (BTP & SaaS) and especially with mobile applications the use of OAuth 2.0 and OIDC has gained stronger importance. IAS supports a mix of both standards. However, mixing always makes the configuration more complicated. Therefore if a corporate IDP supports OIDC and the client uses it, the complete authentication flow is much leaner compared to SAML2/OIDC in combination.
Configuration guideline
You can follow this documentation on help.sap.com. However, the v1 endpoint is still being used there. According to SAP they experienced unexpected behavior and suggested using the v2 endpoint. This information is currently not included in the documentation, for this reason, we suggest following the steps outlined here.
In this example, we use our demo environment with some sandbox systems (nothing secret, so we won’t obfuscate those values here)
Azure Tenant ID: bbffd6ff-54e5-498a-8632-2b05586ee6f9
IAS Tenant: ias.carstenolt.de
Obtaining required information from your Azure tenant
First, obtain the metadata from your Azure AD tenant. OpenID Connect describes a metadata document that contains most of the information required for an app to perform a login. For this, the OP typically publishes its metadata at a well-known URL. To query your discovery or well-known endpoint - use this URL: https://login.microsoftonline.com/<azure-tenant>/v2.0/.well-known/openid-configuration
Result:
{"token_endpoint":"https://login.microsoftonline.com/<azure-tenant>/oauth2/v2.0/token","token_endpoint_auth_methods_supported":["client_secret_post","private_key_jwt","client_secret_basic"],"jwks_uri":"https://login.microsoftonline.com/<azure-tenant>/discovery/v2.0/keys","response_modes_supported":["query","fragment","form_post"],"subject_types_supported":["pairwise"],"id_token_signing_alg_values_supported":["RS256"],"response_types_supported":["code","id_token","code id_token","id_token token"],"scopes_supported":["openid","profile","email","offline_access"],"issuer":"https://login.microsoftonline.com/<azure-tenant>/v2.0","request_uri_parameter_supported":false,"userinfo_endpoint":"https://graph.microsoft.com/oidc/userinfo","authorization_endpoint":"https://login.microsoftonline.com/<azure-tenant>/oauth2/v2.0/authorize","device_authorization_endpoint":"https://login.microsoftonline.com/<azure-tenant>/oauth2/v2.0/devicecode","http_logout_supported":true,"frontchannel_logout_supported":true,"end_session_endpoint":"https://login.microsoftonline.com/<azure-tenant>/oauth2/v2.0/logout","claims_supported":["sub","iss","cloud_instance_name","cloud_instance_host_name","cloud_graph_host_name","msgraph_host","aud","exp","iat","auth_time","acr","nonce","preferred_username","name","tid","ver","at_hash","c_hash","email"],"kerberos_endpoint":"https://login.microsoftonline.com/<azure-tenant>/kerberos","tenant_region_scope":"EU","cloud_instance_name":"microsoftonline.com","cloud_graph_host_name":"graph.windows.net","msgraph_host":"graph.microsoft.com","rbac_url":"https://pas.windows.net"}Setup the OpenID Connect IDP in IAS
On your IAS tenant switch to Identity Providers → Corporate identity providers
and create a new entry - for example: OIDC_IDP
Switch Identity Provider Type to OpenID Connect Compliant:
Now Switch to OpenID Connect configuration and enter the URL: https://login.microsoftonline.com/<azure-tenant>/v2.0/.well-known/openid-configuration
in the field Discovery URL. Press Load, and IAS will populate the Issuer URL from the metadata.
The issuer in this case is: https://login.microsoftonline.com/<azure-tenant>/v2.0
Now we see that we need to enter a Client ID and secret to authorize and validate our OIDC client connection. For this reason, now it’s time to switch to your Azure tenant as we first need to perform some steps there.
We will proceed here later on!
Register IAS as an application in your Azure tenant
In your Azure Portal switch to Azure Active Directory → App registrations.
Add a new registration. Enter a name representing your IAS tenant and choose the supported account types according to your needs. In our scenario, we will just use a single tenant:
After a user successfully authorizes an application, the authorization server will redirect the user back to the application. Hence, we need to add a Redirect URI from type Web with the value: https://<ias-tenant>/oauth2/callback
Azure already created the OAuth 2.0 Client ID for you, in this case 0b35d68a-8420-4b92-952e-67bf1b429978…which is one of the values you will require to finish the configuration on the IAS side:
In the next step add a secret to your Azure app via Add a certificate or secret → New client secret and configure the lifetime according to your policy (ask your Azure experts for advice):
The next screen will show you the new client secret, you need to copy the value of the client secret in your password safe. Please note those values cannot be viewed again, except for immediately after creation. You don't need the Secret ID.
In this case the value is: ~4y8Q*****************************ql which is the second information you will require to finish the configuration on the IAS side.
Summary
Client ID: 0b35d68a-8420-4b92-952e-67bf1b429978
Client Secret: ~4y8Q*****************************ql
Before you finish the configuration on your IAS tenant set up some additional stuff. In the next step, we want to provide the email address of the Azure user to the ID token (JWT) issued from Azure. In addition, we want to provide the groups claim to forward the sAMAccountName of all groups the user is assigned to.
Switch to Token configuration and add email as an optional claim to your ID token (While adding this claim your API permissions may be updated).
In the same way, add the groups claim, and the final result will look like this:
Please note: Your configuration and required claims may vary depending on your environment and requirements, this is just a sample configuration (!)
Finish the OpenID Connect IDP configuration in IAS
Since the app registration, the creation of client credentials, and custom settings have been done on the Azure side, we are ready to finish our configuration on the IAS side.
Back in your ODIC IDP configuration, enter Client ID and Client Secret and Validate the configuration. This will execute a client credential token request to your Azure IDP to verify the credentials:
You can have up to 20 scopes. The openid scope is added by default. Each scope can have a length of up to 99 characters.
For the client credentials flow to work, Azure requires some specific scopes. In our scenario we need to add the scope <azure-client-id></.default> to our configuration:
Update 09-11-22: adding the scope "<azure client id>/.default" in section "Finish the OpenID Connect IDP configuration in IAS" is not required any more for the validate feature (thanks Torsten)
Once added, let’s try again:
Information from SAP support: “Please keep in mind if you provide some further scopes it might lead to some issues for other flows which may require to remove this "/.default" scope again (which will make the client credentials flow fail) but the Corporate IdP configuration will be still valid if the save works. These scenarios depend a lot on the Third-Party Corporate IdP, in that case, Azure”
In our scenario, the user identifier should be obtained from the claim email contained in the received ID token. We defined not to use the sub but instead the email claim that should be used as the subject name identifier for this Corporate Identity Provider:
Technically you can send any attribute, here we just added the email scope, so Azure puts the email address into the “email" claim. In IAS we ensure the "Subject Name Identifier" for the Corporate IdP is "E-Mail" as well, so the user is successfully federated with the user object in the IAS IdDS.
Keep in mind your configuration may vary.
As a prerequisite, you must have enabled the Use Identity Authentication user store for this to work. Of course, we enabled Identity Federation in order to make use of the entire spectrum and flexibility of the IAS:
In addition, we recommend configuring your OpenID Connect IDP name similar to your custom domain from the very beginning (in case you have one in use):
Heureka! Time to test your setup
Obtaining an ID token from your Azure tenant using Postman
In fact, the federation between IAS and Azure uses the OAuth grant-type authorization code. This means that no ID token can be found in your browser by using common tracer tools.
If you are as curious as I am, you can get an ID token directly from your Azure tenant, to see what information is contained there and whether the claims are delivered correctly. There are many ways, here is a simple one using a POST request to the OAuth 2.0 token endpoint (v2) of your Azure tenant via Postman:
As a result, you will receive your “id_token” and you can decode it using jwt.io
Example ID Token:
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjJaUXBKM1VwYmpBWVhZR2FYRUpsOGxWMFRPSSJ9.eyJhdWQiOiIwYjM1ZDY4YS04NDIwLTRiOTItOTUyZS02N2JmMWI0Mjk5NzgiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vYmJmZmQ2ZmYtNTRlNS00OThhLTg2MzItMmIwNTU4NmVlNmY5L3YyLjAiLCJpYXQiOjE2NjUwNTY1MDQsIm5iZiI6MTY2NTA1NjUwNCwiZXhwIjoxNjY1MDYwNDA0LCJlbWFpbCI6ImMub2x0QG5vZW1haWwuY29tIiwiZ3JvdXBzIjpbIlhJVF9BRF9HUk9VUF9TVVBQT1JUIiwiWElUX0FEX0dST1VQX0NPTlNVTFRJTkciLCJYSVRfQURfR1JPVVBfU0NQX1dFQklERSIsIlhJVF9BRF9HUk9VUF9FRFVDQVRJT04iLCJBUklCQV9Hcm91cF9GdW5rdGlvbjEiLCJYSVRfQURfR1JPVVBfQ0NBRE1JTlMiLCJTRlNGX0dyb3VwX0Z1bmN0aW9uMSJdLCJuYW1lIjoiQ2Fyc3RlbiBPbHQiLCJvaWQiOiI0ODAzNTE4My0xNDY4LTQ2ZDQtYjMzYy1mMzRhMDJjMzg0ZjIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJjLm9sdEBjYXJzdGVub2x0LmRlIiwicmgiOiIwLkFURUFfOWJfdS1WVWlrbUdNaXNGV0c3bS1ZcldOUXNnaEpKTGxTNW52eHRDbVhneEFJdy4iLCJzdWIiOiJBbkNpUFZFVU1UUXpSTWtRSFBWUU1qQ2p3el9wSFJRRms0VTl0S0J6Mi13IiwidGlkIjoiYmJmZmQ2ZmYtNTRlNS00OThhLTg2MzItMmIwNTU4NmVlNmY5IiwidXRpIjoiV3V5M01wd3R1a0sxX2NyNmZLazlBQSIsInZlciI6IjIuMCJ9.K6v2-8UnfA2rG8eXBIUSX6CaLGvAzFsIIDmQDTXV1XqCuX9VZSweHy33Q3TU2KwRpCmiXxYo4ccBr8euuIkUZyMgGDlM82GO1uQWZw6WzVIgsj7AXeT-DYD09mKwNTzu11I2_Js3rVdWQGWROXiSCXtF4LfiEarp2t6Sq5bI42t9cdmQYRT9BR9I8b6wVuNu2JJ5RXmXVO5o9Ln59m4NGkK4ZMqR2xCGxkmmUz42hMIdAIpj9vEDIj_01ziUJKftm9LUry4HcBWn4YHKoXtlq0NyukCwI5QFXZ7adMfcjFeqCVXTzGPTm6OOkDFvgEWlQllPR7T-pcpwhid6HA3jlQThe payload contains some important information like the issuer, the intended audience (aud) which is the IAS client ID as well as the claims email and groups.
{
"aud": "0b35d68a-8420-4b92-952e-67bf1b429978",
"iss": "https://login.microsoftonline.com/bbffd6ff-54e5-498a-8632-2b05586ee6f9/v2.0",
"...,
"email": "c.olt@noemail.com",
"groups": [
"XIT_AD_GROUP_CONSULTING",
…"
],
"name": "Carsten Olt",
…"
}Fine, this way you can use the E-Mail claim (email) as subject name identifier for authentication and the groups for authorization purposes.
In a recent project, we had the requirement to mix some groups from the corporate IDP with group claims from IAS. Even with OIDC, this is possible using the Default Attributes.
For example, to enrich the final SAML assertion that will be sent to the application with Azure groups that start with XIT_:
Finally, configure your new OIDC Corporate Identity Provider for your IAS applications (Conditional Authentication)
This article only deals with IAS using OIDC for the Corporate IDP. Depending on your scenario, IAS supports various flows and capabilities, you can read more about them here
We hope this blog was helpful!
- SAP Managed Tags:
25 Comments
