Explained! #1: SAP IAS Proxy Mode and ID-Federation
Xiting Explained! “Unlock the mysteries of SAP Cloud Security” our new blog series offers an in-depth exploration of secure authentication, identity management, and identity and access governance. With the help of our expert guides, readers can gain a deeper understanding of SAP Cloud Identity Services, SAP IDM, SSO, and SAP Cloud Identity Access Governance (IAG).
Table of Contents
Introduction
Welcome to the inaugural post of our Explained! blog series, where we aim to demystify the intricate landscape of SAP Cloud Security. In this first article, we’ll delve into SAP Cloud Identity Services, specifically focusing on the functionality of SAP IAS in Proxy Mode and its Identity Federation capabilities.
SAP Cloud Identity Services are particularly useful for SAP organizations that need to manage user identities and access across multiple hybrid SAP applications and services, as it enables single sign-on (SSO) and provides a consistent user experience:
- Delivered with all major cloud solutions from SAP automated or on-request via self-service.
- No additional cost for usage related to SAP hybrid landscapes.
- Standard authority to access the cloud landscape for business users from SAP.
- One default tenant independent of the number of purchased SAP solutions.
- Test tenant on request for free (Addt. tenants available as well).
- One point to synchronize user information, enable single sign- on, and maintain trust relationships for cloud solutions from SAP.
The SAP Cloud Identity Authentication Service (or SAP IAS) is a cloud-based Identity Provider that enables secure authentication, SSO and identity management for cloud applications. One of the key features of SAP IAS is the Proxy Mode, which allows users to securely access external cloud applications without exposing their credentials. This allows organizations to leverage their existing identity management systems and extend their capabilities to all http-based SAP applications.
This post will cover two topics related to SAP IAS (Identity Authentication Service). First, we will explain how SAP IAS can serve as a proxy between a corporate identity provider and other systems. This means that SAP IAS can facilitate the exchange of authentication and authorization information between the corporate identity provider and other systems.
Second, we will discuss the identity federation settings in SAP IAS. These settings are important but are often overlooked or not fully understood. We will provide more details about what these settings are and why they are important in the context of SAP IAS.
Understanding SAP IAS Proxy Mode
In simple terms, the “proxy mode” in SAP IAS allows you to use your company’s existing SAML identity provider to authenticate users for all your SAP applications. By delegating authentication to an external Identity Provider (IdP), IAS can benefit from proxy integration. This approach allows the corporate IdP to maintain control over all identities, manage their login credentials, and offer additional Single Sign-On (SSO) and security features like Multi-Factor Authentication (MFA).
SAP IAS acts as a middleman between the SAP application and the company’s identity provider, passing along authentication requests and receiving authorization in the form of a SAML assertion. This allows users to access cloud-based applications without having to create new login credentials on SAP IAS. Additionally, the “identity federation” feature in SAP IAS can provide extra layers of security and additional data about the user, independent of the company’s identity provider.
From an authentication perspective, in short here is what happens:
- A user tries to access the target SAP application and is redirected to SAP IAS.
- Based on conditional authentication rules or static configuration, IAS delegates the authentication to the corresponding corporate IdP.
- At this stage, user authentication is required and users benefit from SSO combined with MFA (done via Corporate IdP).
- When Identity Federation and local users are not enabled (as explained below), SAP IAS takes control of the SAML token from the Corporate IdP, reuses the provided subject name ID and other claims plus signs the final SAML assertion that’s used for authenticating with the target application.
- Optional: Using the SAML assertion issued from the corporate IdP, the user is propagated to IAS and the correct identity is determined in the IdDS (Identity Directory Service).
- Optional: As the IAS knows about the user’s attributes and group memberships it applies the configuration of the target application and creates the final SAML assertion (or ID token).
- Optional: SAP IAS uses the desired subject name ID format and attributes like an e-mail address, an employee ID or login name, and even certain group claims and or other custom attributes. This can be done individually for each application in IAS.
One of the key benefits of this approach is that it allows organizations to enforce their existing security policies and access controls across all SAP based http-applications. It also ensures that all authentication requests are handled consistently from SAP IAS across different SAP applications, reducing the risk of security breaches or unauthorized access.
IdP proxies offer various features such as protocol translation, attribute mapping, policy enforcement, and additional security measures like token encryption/decryption. They are often used in federated identity management systems to simplify authentication/authorization management, integrate with multiple service providers, and enhance security.
In the Proxy Mode, Identity Authentication delegates authentication to a trusted identity provider, such as Microsoft Azure. The provider handles the authentication process, generates a SAML token, and sends it to the user’s web browser for accessing the business application. On the other hand, with the Identity Federation enabled, SAP IAS generates the SAML token based on synchronized and enriched user data.
Hint: When functioning as an IdP proxy, it’s not always necessary to have user profiles in the IAS. In this mode, you can avoid creating users in the Identity Directory altogether. However, this is no longer the recommended approach.
This blog won’t provide an in-depth explanation of the entire SAML flow, but if you want to learn more about it, we recommend checking out this link. Additionally, this blog article from Xiting may also be helpful in understanding how SAP IAS works in proxy mode and its coexistence with Azure Active Directory:
Understanding Identity Federation settings in SAP IAS
Another significant concept in this context is Identity Federation, which involves connecting a user’s identity across multiple organizations or systems. Essentially, Identity Federation makes the process of accessing multiple systems simpler and more seamless for users, by allowing them to use the same login credentials across different systems.
When SAP IAS acts as a proxy between the corporate identity provider and other systems, it can influence the authentication process and add additional attributes to the authentication response. This means that instead of relying solely on the corporate identity provider’s authentication response, SAP IAS can modify or enrich the response with additional attributes from its own user store.
For example, an administrator can add a prefix or suffix to the user’s subject name ID and provide additional group memberships as claims to the authentication response. This allows the SAP cloud application to receive more information about the user beyond what is provided by the corporate identity provider. This feature works for both SAML 2.0 and OpenID Connect applications and can be configured for each individual application. Ultimately, this helps to simplify the authentication process and provide a more streamlined user experience.
For example, instead of sending the email address of the user from the corporate identity provider, SAP IAS can send the SAP Global User ID (UUID) as the user’s identifier to a specific SAP cloud application. This information can be formatted (converted to lower or UPPERCASE) in different ways based on the application’s requirements.
The proxy IdP may have the final word on whether the authentication process ultimately succeeds or fails. There are several levels of identity federation configuration to be done for each Corporate Identity Provider that has been configured for your IAS tenant. So far we have seen many implementations where these settings have been neglected or misunderstood, leading to unwanted results.
So we thought it made sense to point this out and explain them in more detail. Three IAS configuration settings to consider when integrating Corporate IdP – these are defined on the Identity Provider level and affect all Service Providers associated with the given Corporate IdP:
- Use Identity Authentication Store: User attributes can be taken from the corporate IdP assertion or from Identity Authentication user store.
- Allow Identity Authentication users only: When enabled, only the users that exist in IAS can access the application.
- Apply Application Configurations: When enabled, the custom application configurations for authentication and access policies are applied. Required to utilize Risk-Based Authentication.
This way the administrator of the SAP 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. This also ensures 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 simplify things, it is advisable to enable all three options when using SAP IAS. However, this requires the creation of user profiles in the Identity Directory (IAS user store) and may involve considering identity and access management (IAM) as well as the source system to provide the user information.
One way to achieve this is by using the SAP Cloud Identity Provisioning Service (IPS), which allows for automatic profile generation through the SCIM 2.0 API. It allows for access to the Identity Directory and the creation of custom schemas and attributes. Users, groups, and group assignments can be programmatically accessed and modified, with a maximum of 20 custom schemas with 20 custom attributes each.
Of course, the data is not only visible through APIs but also in the user interface of the Identity Authentication service itself. Under User Management and User Groups, the data is sourced directly from the Identity Directory.
Persisting user profiles is crucial for achieving centralized management, enabling single sign-on, improving scalability, facilitating integration with other systems, and preparing for future SAP cloud applications.
Hint: Think of SAP IAS not just as an Identity Provider, but as a central user store that consolidates all identities in one place, similar to a central user administration (CUA). It acts as a single source of truth, generating important attributes like the SAP Global User ID and can be enhanced with attributes from other source systems.This creates a centralized user identity that can be used to access the entire SAP cloud ecosystem and to ensure automated management. The Identity Directory is essential for many new features and SAP cloud applications, including SAP SuccessFactors, SAP Task Center, and SAP Identity Access Governance. For instance, SAP Task Center relies on the user’s Unique Universal Identifier generated during creation in the Identity Directory to accurately map tasks to specific SAP solutions.
To explore further details and real-world use cases, we recommend reading this blog post on the SAP Community:
https://blogs.sap.com/2022/02/08/options-to-manipulate-the-subject-name-id-coming-from-the-corporate-idp-in-proxy-scenarios/ or the Link to the SAP documentation.
Frequently Asked Questions
Yes, it is possible to use IAS as a pure proxy w/o having local users created in the identity directory. However, there are disadvantages, and it may not be a future-proof solution to support all SAP cloud applications.
Instead of using the subject name ID, you can configure Identity Authentication to forward a different attribute as the subject name ID. To do this, use the syntax: ${corporateIdP.<corporateIDP attribute>}, where <corporateIDP attribute> is the full technical name of the attribute that contains the necessary value for the application. It’s important to ensure that this attribute is included in the assertion from your corporate IdP.
No, they do not require a password, they just need to authenticate against the corporate identity provider, and that’s it.
When combined with the “Use Identity Authentication user store” option, this feature allows end-users to continue using the corporate IdP for authentication. During the authentication process, the subject name ID sent from the corporate IdP in the first response to SAP IAS – usually the user’s email address or UPN – is used to verify the existence of the user’s profile in the SAP IAS user store, also known as the Identity Directory. SAP IAS then retrieves the required user attributes from its own user store and forwards them to the application for further processing.
Users can be created through various methods, such as manual creation, CSV-import, self-registration, or by using the SCIM API. 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.
Conclusion and Benefits
In summary, SAP IAS can act as a proxy towards a corporate identity provider, enabling organizations to leverage their existing identity management systems and extend their capabilities to cloud-based applications.
In addition to acting as a proxy towards a corporate identity provider, SAP IAS also provides identity federation settings which brings the following advantages:
- Service-provider-specific attribute mapping/rewriting and assertion enrichment, without the need to adjust the corporate identity provider.
- Allows flexible SAML NameID and claims configuration for each SAP application.
- Easy separation mechanism for multiple user stores (internal, external, and employees) allowing the flexibility to configure where user credentials are validated.
- Allows to authenticate external users like partners and customers, directly at the IAS without being known in the corporate IdP (IDP-initiated authentication via a special URL).
- One SSO session for all SAP cloud applications, with the option to enforce separate access control policies and having a single audit log for authentication.
- SAP IAS can act as a policy enforcement point, allowing administrators to control the access to specific resources based on risk-based authentication rules and multi-factor authentication including FIDO2 support.
- SAP IAS provides a single point of configuration and management for multiple SPs and IDPs, simplifying the management of SAML-based federations.
- Choice between SAML and OpenID Connect, including protocol conversion towards SAP applications (even if the corporate IdP does not support OIDC yet).
- Foundation that is required for implementing identity lifecycle management using SAP Identity Provisioning Service (IPS) or Identity Management (IDM) solutions. Identity lifecycle management involves the management of user identities throughout their entire lifecycle, from creation to termination, and includes tasks such as provisioning/de-provisioning, access management, and compliance monitoring.
Stay tuned for our next post in the “Explained!” series, where we’ll discuss more topics related to SAP Cloud Identity Services and Co.
With a security-minded approach, Carsten has international project and IT security experience in many industries. He has been working in IT-Security since 2001, specializing in SAP security since 2010. He is a subject matter expert for SAP Single Sign-On 3.0 and a trainer for the WDESSO course. His current focus is on supporting customers in solving authentication and security challenges within hybrid SAP landscapes, as well as designing and implementing holistic authentication concepts. Carsten is an ISACA CISA and a former MCP and RHCE with an ISP background, and he looks at security from different angles. He also translates between SAP and IT security vocabulary.
Carsten has in-depth experience in multi-vendor architectures and MSFT/Azure components, dealing with all the requirements concerning SAML 2.0, OAuth, OpenID Connect, SCIM, X.509 CBA & PKI, MFA, SAP SSO, and Secure Network Communications, Kerberos/SPNEGO, data security and encryption, as well as digital signatures.
Carsten is experienced in SAP on-premises components such as S/4HANA, ABAP, and Java, as well as security solutions like SSO 3.0. Since 2019, he has focused on SAP-Cloudified environments, specifically the SAP Cloud Identity Services and SAP BTP, as well as SaaS integrations concerning IAM. He deals with hybrid SAP security in conjunction with Azure Active Directory, ADDS, ADFS, ADCS, Reverse Proxies/WAF, SAP Web Dispatcher, SAP Cloud Connector, third-party products, and infrastructure components.
- Cloud Integration Made Easy: Xiting Central Workflows (XCW) Meets SAP Cloud - 30. July 2024
- From Nostalgia to Excitement: The Impending End of SAP IDM - 15. March 2024
- 2024 SAP Cloud Identity Services & IAM Portfolio: What’s New? - 23. February 2024
