Deciphering Seamless SAML Single Sign-On: A Comprehensive Guide to Multi-Identity Provider Integration with SAP IAS as Your Proxy for S/4 HANA and Beyond (Part 1)

Abstract:

In this extensive blog post two series, I offer a detailed, step-by-step guide for setting up Single Sign-On (SSO) using SAP Identity Authentication Service (IAS) across multiple Identity Providers (IdPs). In our approach , Identity Authentication (IAS) acts as a proxy identity provider where Azure, Google, AWS, and the company Active Directory play as the main authentication authority for the applications. The objective is to ensure providing smooth access to S/4 HANA, SaaS, PaaS, and on premises applications in SAP landscape.

While numerous resources cover this topic, I understand the URGENT ongoing need for a focused and practical approach that delves into the implementation detail for a cloud native approach.

This guide provides hands-on insights, FOSTERING confidence in the successful deployment of a well-documented solution for both SAP customers and partners. It’s important to note that many solutions in the market lack full integration with various vendors and a strategic vision, potentially hindering future deployments as businesses expand their IT solutions.

When dealing with user provisioning, SAP Identity Access Governance, IAG plays a vital role, particularly in automating user creation or de-provisioning process. However, to maintain our focus on SSO, this blog excludes a discussion of IAG.

SAP Cloud Identity Services includes three components:

1-Identity Authenticate Service (IAS):

IAS is a cloud based SAML2 identity provider that offers an Identity Service tailored to business processes, applications, and data. It delivers single sign-on and seamless integration with both SAP and non-SAP applications, whether they are in cloud or on-premises.

Identity Authentication offers one productive and one test tenant per customer, irrespective of the number of contracts (signed with SAP) that include or bundle Identity Authentication. A bundled tenant is not restricted in functionality; it provides access to the complete range of features offered by Identity Authentication.

If you have a mobile application, the preferred protocol is to use OpenID Connect in IAS. Conversely, if your use case involves Identity Authentication serving as a proxy to multiple identity providers and enabling partner users to log in via their corporate identity providers, then SAML 2.0 is the appropriate choice.

The primary features of IAS are illustrated in the diagram below, providing a visual guide to familiarize you with its functions:

IAS Features

Given that we employ IAS as a comprehensive proxy for the Identity Provider, the intended architecture to realize this objective appears as follows:

IAS SSO intended Architecture

2-Identity Provisioning Service:

The Identity Provisioning Service (IPS) can effectively oversee and automate identity lifecycle processes for both cloud and on-premises environments. IPS also takes care of the seamless provisioning of users and groups, ensuring a smooth transition from source to target systems.

IPS overview

3-Identity Directory:

It stores and persists user / group data, offering a System for Cross-domain Identity Management (SCIM) API for the management of resources, including users, groups, and customized schemas. The provisioning of these entities to and from the directory is guaranteed by the Local Identity Directory connector within the Identity Provisioning service. Upon the creation of a new user, the directory generates a Global User ID, which serves as the distinctive user identifier across the landscape. Identity Provisioning subsequently distributes this Global User ID to SAP cloud applications.

Features such as Identify Federation and Unique Universal Identifier in IAS are examples of Identity Directory use.

As depicted in the diagram below, the Identity Directory is an integral and inseparable component of the Identity Provisioning Service’s lifecycle management:

Identity Directory Overview

In summary, SAP Cloud Identity Service (SCI) is tasked with three main functions, as illustrated in the diagram below:

SAP Identity Service main tasks

Solutions for provisioning users for your SAP landscape

In our approach we assumed business users exist in IdP, IAS, and the target applications. The diagram below shows the three high level states of using IPS to replicate users and since customer already obtained SAP Cloud identity service IPS as a part of the offering it can be leveraged at least to replicate users in SAP Business applications:

Provision users by IPS

Here, I present two widely adopted methods in the market for provisioning SAP business users:

Customer Identity Management is the source system (User Store) to provision users from:

User provision triggers by customer IdP

SAP Employee Central (SF) is the source system (User Store) to provision users from:

User provision triggers by SF

Given your familiarity with SAP Identity Authentication Service and its dependencies on other components within SAP Cloud Identity, now I can unveil the architecture diagram for IAS as a complete IdP proxy for SSO integration that we’re set to implement:

IAS Architecture as IdP Proxy

In the diagram above you notice that the Identity Authentication Service (IAS) takes center stage as the central hub and proxy. Our primary goal is to establish trust (SAML2, for instance) between multiple Identity Providers (IdPs) and IAS, and subsequently, between IAS and a multitude of applications, including PaaS, SaaS, and S/4 HANA.

You may detect that SAP SaaS applications can establish connectivity with the S/4 HANA Private edition on a Hyperscaler platform via SAP Cloud Connector, allowing access through Fiori tiles. Additionally, these applications can be conveniently accessed directly via Single Sign-On (SSO) thanks to the deployment of IAS!

The beauty of this approach lies in its Single Sign-On (SSO) initiation from IAS. You only need to establish trust once between IAS and your desired application. When it comes to incorporating new IdP domains or even integrating corporate identities on-premises, the process is as straightforward as adding them to IAS (as a new IdP) and configuring trust. Importantly, this can be accomplished without any need to alter the application or its existing trust relationship with IAS.

What’s more, the addition of a new IdP has no adverse effects on other IdPs or your existing connections, making this an elegant and efficient solution.

IAS implementation methods:

It is recommended to exclusively UTILIZE the Production IAS tenant for all interactions with end users, regardless of whether it’s within a development or testing environment of the application they are accessing. Other IAS tenants should be reserved solely for the testing of identity-related configurations, ensuring these tests are kept separate from the Production tenant.

This approach will provide you with a centralized platform to manage, integrate, monitor, and audit your identity-related processes, further enhancing the efficiency and security of your operations.

The diagram below illustrates the utilization of multiple Identity Providers within a single IAS tenant:

IAS with multiple IdPs

You have the flexibility to employ multiple IAS tenants across various regions, aligning with the company’s headquarters or different tiers, as depicted in the diagram below:

Multi IAS with multiple IdPs

IAS High Availability/Disaster Recovery:

Like any solution deployed in Cloud you expect to have a Service Level Agreement (SLA) with SAP IAS and that is true here too. IAS tenant is managed by SAP, and it is a multi-tenant solution meaning more than one tenant shares the hardware in backend. You can directly reach out to your SAP contact to ask about your IAS tenant HA/DR existing setup.

Normally the tenant is provisioned in a region with two availability zones by the cloud provider that can support the HA (at minimum) and for the DR your SAP representee can confirm do they have a replica for the primary tenant in a secondary region if that exists. According to SAP doc a full backup will be performed every day at 01:00 UTC and it is kept for 90 days.

IAS HA/DR

Before we start the configuration in IAS, the organization requirement for SSO is to use employee id or email as unique identifier if it is possible and the login method in any IdP was requested to be the cooperate email and password.

Based on the requirement from the company, the assertion attributes we choose is as follow:

Selected Assertion Attributes

IAS SSO high level steps

By following the above outlined steps and its underlying principles of establishing trust across various layers you easily can setup your SSO in multi clouds and on premises. In the context of the SAML XML exchange, the standard approach starts from the Service Provider to initiate the exchange by downloading the SAML2 XMLL and subsequently uploading that on the other side.

SSO XML Metadata Exchange

This two sides trust make this architecture work instantly.

There is trust configured in Applications towards IAS which in turn is set up to federate with IdPs as Corporate Identity Provider.

For certificate management we can follow below pattern:

Applications Certificate: when this changes, the IAS Applications’ SAML2 must be updated.
Tenant certificate: when this changes, both Applications’ SAML2 outside of IAS and inside IdP must be updated.
IdPs Enterprise Applications: when this changes, the Corporate Identity Provider’s SAML2 in IAS must be updated.

IAS SSO certificates update

Practical Showcase: The remainder of this blog offers a comprehensive walkthrough, complete with detailed steps and snapshots, showcasing an IAS Single Sign-On (SSO) implementation. Drawing parallels with a real case I successfully executed for my clients, this section serves as a practical guide for you to follow and apply in your own environment.

We assume that business users are uniquely established across all three layers: IAS, IdP, and target systems. While the approach to provisioning users and managing their Access Control may vary, each method relies on the foundational processes of IPS and IAG.

Corporate IdP in IAS:

IAS, functioning as an identity provider proxy, acts as a SAML 2.0 identity provider, both for applications and the corporate identity provider. Once a user undergoes authentication at the corporate identity provider, any follow-up authentication requests from the service provider, utilizing the same corporate identity provider, will not be rerouted to it, provided the session at Identity Authentication remains active. During the initial authentication, Identity Authentication produces assertions based on the user data it receives.

To establish a corporate Identity Provider (IdP) in IAS for a new tenant (domain) from Azure, AWS, and Google, the initial step involves sharing the IAS Tenant SAML2 (downloaded files) with the respective cloud teams. Subsequently, they furnish us with their IdP response, enabling the creation of a new corporate IdP in IAS.

This process is regarded as a one-time effort for establishing a corporate IdP for a new tenant (domain) in IAS.

Download IAS Tenant SAML2 Metadata

Connect to the IAS tenant administration console by using the console’s URL: http://<tenantid>.accounts.ondemand.com/admin
Choose Tenant Setting tile under Application & Resources
Select the SAML2.0 Configuration
Select Download Metadata File to get .XML file
Under Signing Certificates click on glass icon to get the certificate:

Make sure copy and paste the cert content in a notpad.cer file

Open the saved file (in a Windows desktop) and export the public key out of it by following the steps below:

Open the .cer certificate and click on the Details tab and choose public key then click on Copy to a File:

In the next screen click Next:
Subsequently just choose the first option then click on Next :

Select your File name then click on Next to choose Finish to have your Export successfully:

Share these files with your cloud team to use them either by uploading the XML or using the public certificate in new cloud tenant domain to be able to provide you the response XML.

I explain the steps to use this SAML2 XML in the cloud side following the coming section .

Create a new Corporate IdP in IAS:

Make sure you are already signed in to your IAS administrator console
Select Corporate identity Provider tile under Identity Providers
Select the Create button to create a new corporate Identity Provider and after entering the name click on Save
In the new Identity Provider select SAML2.0 Configuration under SAML2.0
Upload your cloud AD metadata XML file (you received for the Cloud IdP team after they upload IAS tenant in Cloud tenant) by clicking on Browse choose your file and select Save:

SAML2.0 Config

Note: to get the SAML2 XML response file from a Cloud Tenant ,please check the step: Request SAML XML response from cloud tenants in following section

6.For Identity Provider Type in Azure you can choose option 3 :

Azure Identity Provider Type

For AWS and Google please make sure you choose the first option:

Google/AWS Identity Provider Type

For Name ID Policy you can follow below recommended setting and make sure your Single Sign-On is ON:

Name ID Policy

For Identity Federation you can have User Store ON to use the benofit of user store from IAS:

Identity Federation

Request SAML XML response from cloud tenants

Since the process to provide the XML response for a new domain for each cloud provider is a little bit different, I just provide some high-level steps for each as following:

Build SAML trust in Azure:

Create an Azure Fiori dummy application to produce a response for the IAS tenant XML:

Connect to Microsoft Entra ID>Enterprise applications >Click on New application

Azure Enterprise Applications

2. Select SAP then SAP Fiori App:

Azure Entra Gallery

3.Fill up your name and click on Create:

Azure Fiori App

4.In new Fiori app click on Set up single sign on and then click on Get started link:

Set up single sign on

5.In single sign-on screen click on SAML box:

Azure SAML

6.In new screen click on Upload metadata file to upload the XML metadata you generated from the IAS tenant earlier:

Upload SAML2 XML in Azure App

7.After upload the file you need to enter a Fiori link for the Sign on URL then click on Save

8.Make sure you have the required attributes in Attributes & Claims You can always click on Edit to remove, add or update any attribute or the unique identifier suit your need:

In single sign-on section of this new app you can download both certificate (Base64) and the Federation Metadata XML:

Download Azure App SAML XML

As you can see, the XML file from the IAS tenant was uploaded here to get this Azure federation response. Subsequently this SAML certificate response is used for creating the Corporate Identity provider in IAS IdP for this Azure new domain.

Please ask the SAP Basis team to provide you the SAML XML file from the respective S/4 system to upload in any new Azure Fiori app and make sure its Fiori link URL enter as a sign on URL if you are going to use this app to publish in Azure Apps.

For any Azure app to reflect a S/4 tier, you just need to upload the SAML XML file from S/4 in Azure App, and it will populate required links in your App. The SAML trust between IAS and Azure tenant was already established by the Fiori dummy app XML and it will be sufficient to able you to connect to any S/4 tier through a browser without requiring to deploy any relevant app in Azure.

Build SAML trust in Google:

In Google Admin console, go to Menu:Apps >Web and mobile apps
Click on Add app>Search for apps
In search field enter “SAP Cloud Platform Identity Authentication”
Select this app
After you provide ACR URL and Entity ID from the IAS tenant to fill up in this new application in Service Provider, details section, the IAS tenant XML can be upload in this app then the metadata can be download to be used in IAS Corporate Identity Provider:
Make sure the attributes are updated under Attribute mapping:

Cross check the name ID setup under Service provider details:

You can pick up the ACR URL and Entity ID from the IAS tenant or as below pattern:

ACS URL: https://your-domain.accounts.ondemand.com/saml2/idp/acs/your-domain.accounts.ondemand.com
Entity ID: https://your-domain.accounts.ondemand.com

If you are going to publish multiple Fiori apps for different S/4 HANA tiers in Google you can create a custom app in Google for each and only provide ACR URL and Entity ID for the S/4 tier which will be the full Fiori link and FQDN similar as below:

ACR URL: https://vh***ds4ci.hec.*****.ca:44300/sap/bc/ui2/flp?sap-client=100&sap-language=EN

Entity ID: https://vh***ds4ci.****.ca

Create a custom app for a new Fiori link in Google:

In Google Admin console, go to Menu: Apps >Web and mobile apps
Click on Add app>Add custom SAML app

After choosing a name for your app in below screen make sure fill up ACS URL, Entity ID and require fields for Attributes and Name ID same as before:

Build SAML trust in AWS:

Log on to AWS console go to IAM Identity Center> Applications >Add application :
Enter the word “SAP” in search and then choose “SAP Cloud Platform CF” click next
In Configuration application page enter your name and description and then click on Upload application SAML metadata file and use your IAS tenant XML file
After the file uploaded you can edit attribute mapping and assign any users to this application:
Click on Edit Configuration to go back to the app to download the AWS Federation XML is used in IAS new Corporate Identity Provider for this domain.
Click on Edit Attributes Mappings to be able update your required attributes then Save Changes:
The final look:

If you are going to publish multiple Fiori apps for different S/4 HANA tiers, you can create a custom app in AWS for each and only provide ACR URL and Entity ID for the tier which will be the full Fiori link and server name similar to below:

ACR URL: https://vh***ds4ci.hec.*****.ca:44300/sap/bc/ui2/flp?sap-client=100&sap-language=EN

Entity ID: https://vh***ds4ci.****.ca

Create a custom app for a new Fiori link in AWS:

Go to IAM Identity Center >Applications >Add Applications
Choose “Add custom SAML.2 application” and click on Next:
In the next screen just upload S/4 HANA SAML2 XML file you generated in S/4 HANA system

If you are going to test your connectivity after the XML Metadata uploaded in SAP Corporate Identity side, you just use AWS access portal URL and utilize your user id and password to test your connectivity via AWS portal.

Establish a SMAL2 trust between S/4 and IAS:

Activate required SAP parameters and web services in S/4 HANA system Log on to ABAB system client make sure the single sing-on parameters is as below via SAP transaction code RZ01:login/create_sso2_ticket = 2   login/accept_sso2_ticket = 1   login/ticketcache_entries_max = 1000   login/ticketcache_off = 0   login/ticket_only_by_https = 1   icf/set_HTTPonly_flag_on_cookies = 0   icf/user_recheck = 1
http/security_session_timeout = 1800

http/security_context_cache_size = 2500

rdisp/plugin_auto_logout = 1800

rdisp/autothtime = 60
Go to transaction SMICM and confirm the HTTPS services are active:
Go to transaction SICF and activate two internet communication Farmwork (ICF) services:

     /default_host/sap/public/bc/sec/saml2

    /default_host/sap/public/bc/sec/cdc_ext_service

Create the SAML 2.0 local Provider in transaction SAML2

In ABAB system go to transaction code SAML2 in new user interface browser chose Create SAML2.0 Local Provider

Choose a name for your provider like https://DS4100 and select the Finish
Download SAP Local Provider SAML2.0 metadata (it will be used in S/4 HANA IAS APP)

Configure the trusted provider in transaction SAML2 in S/4

In transaction SAMl2 select Trusted Provider tab click on Add to be able to upload file:
Upload the IAS tenant SAML XML file was downloaded earlier from IAS tenant(you can next upload .the public key to prevent the manual configuration we are going through)
Select Next for Metadata verification and then Select Provider
Enter an alias for the Provider name
For Signature and Encryption choose SHA-256:
Choose HTTP POST for Single Sign-On Endpoints
Choose HTTP Redirect for Single Logout Endpoints
For next two steps (Artifact Endpoints and Authentication Requirements) keep the default and select Finish.

Enable the identity provider in S/4

Under Trusted Provider tab choose the identity provider for IAS then click on Enable
Confirm that the identity Provider is active

Configure name ID format for the ABAP system

In Trusted Providers tab click on the identity provider that you enabled before and choose Edit:
On the Identity Federation tab under Support Name ID Formats select Add
Choose E-mail in the Supported Name ID Formats box then click OK
This automatically sets the User ID source and User ID Mapping Mode to Email then choose Save
In Identity Federation tab click on Add and choose Employee Number and change the Default Name ID to Employee_number if you are going to have that as the unique identifier across all IdPs then choose Save

Create your S/4 HANA App in IAS

Open Application and Resources-> Application
Click on Create after enter Application Display Name as DS4_100.
Navigate to ‘SAML 2.0 Configuration’. click on Browse to upload the downloaded metadata file from S/4 HANA local provider.
In Subject Name Identifier used advanced option and select employee number as name identifier value:
In SAML Assertion Attributes we used below assertions:
In Conditional Authentication make sure you add your IdP domain and turn-on the “Trust all Corporate Identity Providers” to be activated in the application

How set User Store and Configure Identity Federation:

You can set User store option ON in Identify Federation of Corporate Identity Provider if you want to have IAS as user store too. Set this option off if you decided to use the user store from your IdP corporate Identity only. This option will be applicable for users log on through the corporate IdP. The rest of the options in corroborate IdP are very self-explanatory.

How configure Issuer Name at Identity Authentication:

In your IAS Application in Configure SAML2.0 Request to Corporate Identity Provider section you can allow IdP to sent Authentication context or not:

Create SaaS / PaaS APP as a target App in IAS:

We assumed we already set up the cooperate IdP in IAS, next we need to add our SAP SaaS Applications like SuccessFactors in IAS to use the SSO benefit when we login to this application.

Below I provide you two examples for SAP and Non-SAP app integrated in IAS SSO:

Create SuccessFactors App in IAS:

The general process will be, to exchange IAS Tenant XML with the SuccessFactors team to upload in their tenant side and instruct the team to make sure the assertion attributes are same as the IAS side.

Then request XML response from the SuccessFactors team to upload in SF app in IAS

Open Application and Resources-> Application
Click on Create and Enter Application Display Name as B13_100.
Navigate to ‘SAML 2.0 Configuration’. upload the downloaded metadata file from B13 100 local provider by clicking on Browse.
In Subject Name Identifier used advanced and employee number as name identifier (Same as S/4 APP)
In SAML Assertion Attributes used assertions similar to S/4 App
In Conditional Authentication make sure you add your IdP domain email and turn-on the “Trust all Corporate Identity Providers” to be activated in the application

Create Workforce App in IAS:

Open Application and Resources-> Application
Click on Create and Enter Application Display Name as Workforce
Fill up your name and click on Create
Navigate to ‘SAML 2.0 Configuration ’upload the metadata file shared by Workforce Team by clicking on Browse
For Subject Name Identifiers, Attributes, and Conditional Authentication you can follow the previous app deployment.

Conclusion

At the heart of SAP Cloud Identity Service is IAS, a pivotal component in today’s SAP landscape, particularly in the critical realm of the Zero Trust approach, where SSO serves as the primary authentication method.

IAS excels in seamlessly bringing together SAP and non-SAP solutions across diverse cloud and hybrid environments. The key to this success involves meticulously establishing trust connections across different layers, with IAS acting as the central hub for all interconnected solutions.

Stay tuned for Part 2 of this blog series, where I will delve into advanced concepts and present a comprehensive set of Q&A tailored to enhance your troubleshooting skills. This will ensure a smooth implementation of Single Sign-On through IAS.

References:

Identity Authentication Configuration for S./4 HANA on premises (Main)

Configure Identity Federation

Microsoft Entra single sign-on (SSO) integration with SAP Cloud Identity Services

Abstract:

Conclusion

Share with others and Connect with us!