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:
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
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:
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:
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:
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:
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:
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:
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:
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:
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 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
Configure the trusted provider in transaction SAML2 in S/4
Enable the identity provider in S/4
Configure name ID format for the ABAP system
Create your S/4 HANA App in IAS:
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 or 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
Create Workforce App in IAS:
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:
Google and SAP Cloud Platform Identity Authentication application
Please leave your comment if you have anything to add!
If you would like to ask questions, please use the community Q&A.
Give us a like and share on social media if you feel it was useful!
You can follow me in People SAP LINK
Thanks!