Hi,
In this blog, I will explain how Single Sign-On works in SAP BTP environment using SAP Identity Authentication Service (IAS) integrated with an external identity provider like Microsoft Entra ID (formerly Azure AD).
This blog is the first part of a two-part series. Part 1 focuses on concepts and architecture.
While Part 2 will focus on Technical setup and configuration.
So, what is SSO?
Single Sign-On is like a master key. You use it to unlock the main door, and from there, every other door you are permitted to enter opens automatically — no extra keys needed.
Imagine your organization has 10 applications, and you have access to 5 of them — each with its own separate set of credentials. Keeping track of all those usernames and passwords can quickly become frustrating and overwhelming.
With SSO, you log in just once, and you are automatically granted access to every application you are permitted to use — no additional logins required.
In this article, we explore an enterprise identity architecture that leverages Microsoft Entra ID in conjunction with SAP Identity Authentication Service (IAS) to establish a robust and scalable authentication mechanism — enabling users to securely access SAP Business Technology Platform (BTP) and a wide range of SAP applications.
As illustrated in the diagram below, the architecture is structured around three distinct layers:
Microsoft Entra ID assumes the role of the Leading Identity Provider (IdP), serving as the authoritative system responsible for verifying user identities, enforcing Multi-Factor Authentication (MFA), and applying conditional access policies.
SAP Identity Authentication Service (IAS) operates as the Proxy Identity Provider, acting as a trusted intermediary that brokers authentication requests between Microsoft Entra ID and the downstream SAP applications.
Finally, the SAP applications themselves — including SAP BTP (subaccount), SAP S/4HANA Cloud, SAP Success Factors, and others — function as the Service Providers (SP), relying on the assertions issued through this identity chain to grant users seamless and secure access.
When a user initiates a login request, it is routed through this layered identity framework. Microsoft Entra ID evaluates the request against the defined authentication and access policies, and issues either an approval or a denial accordingly. Upon successful authentication, a SAML assertion is generated and passed back through SAP IAS to the target SAP application, granting the user access. This structured request-and-response mechanism forms the foundation of how user identities are validated and how access to enterprise applications is governed within a Single Sign-On environment — ensuring a secure, consistent, and seamless experience across the entire SAP landscape.
Key Benefits of bringing in IAS as a proxy IdP
Isolation and Buffering – isolate SAP systems from direct exposure to external authentication flowsAudit and Monitoring – detailed logs of authentication attempts, failures, and user activityFailover and Redundancy – IAS supports multiple IdPs, in case Azure Entra is not available or the organization wants to bring in another external IdP.
Approaches to Single Sign-On
There are two approaches to establishing SSO
Option 1: Service Provider initiated SSO
Assuming in this example, SAP BTP sub account is the service provider and that is where the user wants to login. We call it ‘SAP app’.
The user will directly hit the SAP app URL
SAP app redirects to IAS instead of asking the password itself (Request 1)
SAP IAS doesn’t authenticate; it delegates because IAS recognizes that Entra ID is the master IdP (Request 2)
Entra ID authenticates the user, this is where the actual login happens, credentials are asked – userID, password, MFA (if enabled)
Once authenticated, Entra ID sends the assertion back to IAS (SAML Response/Response 2)
IAS passes the assertion to the SAP app (Response 1)
User gets access: The SAP app trusts IAS, IAS trusted MS Entra ID, Entra ID verified the user and so the user is allowed to access the SAP app.
Note that in SP initiated SSO, SP creates an authentication request which Includes:
Request IDTimestampAudience (SP entity ID)RelayState / redirect target
And the IdP responds to it.
Used responses are rejected, hence this method is more secure and auditable, Strong binding between request and response.
Option 2: Identity Provider initiated SSO
Entra ID sends SAML assertion to SAP IAS, essentially saying “this user just logged in, here’s everything you need to know about them”
IAS accepts the assertion, looks up the user in its directory, and applies any of its own rules
The user now navigates the launchpad — SuccessFactors, Ariba, S/4HANA, etc. They click one.
Since the user is already authenticated, IAS immediately forwards the trust to the chosen SAP app. No redirect back to MS Entra ID. No login prompt again.
User gets access to SAP app.
It is important to note that in this scenario there is no request from the application, only the response is sent from IdP.
There is no original request to validate against and hence nothing to mark the response as already used. This opens the door to:
Replay attacksAssertion reuseSession confusion
In the second part, I will walk through the SSO setup and configuration steps, covering trust establishment, role of IAS, IAS groups and integration considerations between SAP BTP and the enterprise IdP.
Regards,
Shoeb
Hi,In this blog, I will explain how Single Sign-On works in SAP BTP environment using SAP Identity Authentication Service (IAS) integrated with an external identity provider like Microsoft Entra ID (formerly Azure AD).This blog is the first part of a two-part series. Part 1 focuses on concepts and architecture.While Part 2 will focus on Technical setup and configuration.So, what is SSO?Single Sign-On is like a master key. You use it to unlock the main door, and from there, every other door you are permitted to enter opens automatically — no extra keys needed.Imagine your organization has 10 applications, and you have access to 5 of them — each with its own separate set of credentials. Keeping track of all those usernames and passwords can quickly become frustrating and overwhelming.With SSO, you log in just once, and you are automatically granted access to every application you are permitted to use — no additional logins required. In this article, we explore an enterprise identity architecture that leverages Microsoft Entra ID in conjunction with SAP Identity Authentication Service (IAS) to establish a robust and scalable authentication mechanism — enabling users to securely access SAP Business Technology Platform (BTP) and a wide range of SAP applications.As illustrated in the diagram below, the architecture is structured around three distinct layers:Microsoft Entra ID assumes the role of the Leading Identity Provider (IdP), serving as the authoritative system responsible for verifying user identities, enforcing Multi-Factor Authentication (MFA), and applying conditional access policies.SAP Identity Authentication Service (IAS) operates as the Proxy Identity Provider, acting as a trusted intermediary that brokers authentication requests between Microsoft Entra ID and the downstream SAP applications.Finally, the SAP applications themselves — including SAP BTP (subaccount), SAP S/4HANA Cloud, SAP Success Factors, and others — function as the Service Providers (SP), relying on the assertions issued through this identity chain to grant users seamless and secure access.When a user initiates a login request, it is routed through this layered identity framework. Microsoft Entra ID evaluates the request against the defined authentication and access policies, and issues either an approval or a denial accordingly. Upon successful authentication, a SAML assertion is generated and passed back through SAP IAS to the target SAP application, granting the user access. This structured request-and-response mechanism forms the foundation of how user identities are validated and how access to enterprise applications is governed within a Single Sign-On environment — ensuring a secure, consistent, and seamless experience across the entire SAP landscape. Key Benefits of bringing in IAS as a proxy IdPIsolation and Buffering – isolate SAP systems from direct exposure to external authentication flowsAudit and Monitoring – detailed logs of authentication attempts, failures, and user activityFailover and Redundancy – IAS supports multiple IdPs, in case Azure Entra is not available or the organization wants to bring in another external IdP. Approaches to Single Sign-OnThere are two approaches to establishing SSOOption 1: Service Provider initiated SSOAssuming in this example, SAP BTP sub account is the service provider and that is where the user wants to login. We call it ‘SAP app’.The user will directly hit the SAP app URLSAP app redirects to IAS instead of asking the password itself (Request 1) SAP IAS doesn’t authenticate; it delegates because IAS recognizes that Entra ID is the master IdP (Request 2) Entra ID authenticates the user, this is where the actual login happens, credentials are asked – userID, password, MFA (if enabled)Once authenticated, Entra ID sends the assertion back to IAS (SAML Response/Response 2) IAS passes the assertion to the SAP app (Response 1)User gets access: The SAP app trusts IAS, IAS trusted MS Entra ID, Entra ID verified the user and so the user is allowed to access the SAP app.Note that in SP initiated SSO, SP creates an authentication request which Includes:Request IDTimestampAudience (SP entity ID)RelayState / redirect targetAnd the IdP responds to it.Used responses are rejected, hence this method is more secure and auditable, Strong binding between request and response. Option 2: Identity Provider initiated SSO Have a look at the diagram, the user logs in directly to the IdP – Microsoft Entra ID Microsoft Entra asks for the credentials, userID, password and MFA (if enabled), user authentication is done here Entra ID sends SAML assertion to SAP IAS, essentially saying “this user just logged in, here’s everything you need to know about them” IAS accepts the assertion, looks up the user in its directory, and applies any of its own rulesThe user now navigates the launchpad — SuccessFactors, Ariba, S/4HANA, etc. They click one.Since the user is already authenticated, IAS immediately forwards the trust to the chosen SAP app. No redirect back to MS Entra ID. No login prompt again.User gets access to SAP app. It is important to note that in this scenario there is no request from the application, only the response is sent from IdP.There is no original request to validate against and hence nothing to mark the response as already used. This opens the door to:Replay attacksAssertion reuseSession confusion In the second part, I will walk through the SSO setup and configuration steps, covering trust establishment, role of IAS, IAS groups and integration considerations between SAP BTP and the enterprise IdP. Regards, Shoeb Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
