Explaining Authentication Reference Architecture

The main idea behind this reference architecture is that Cloud leading authentication involves identity providers, service providers, and IAM services in SAP BTP. Identity providers assert user information to service providers, issuing security tokens to avoid repeated authentication. Service providers on the other hand, offer the services users need.

The figure explains the SAP Cloud Identity Services architecture.

Identity Authentication can act as a standalone identity provider or broker, redirecting authentication requests to a configured identity provider. This setup is common when using a central identity provider (IdP) across target systems and works with new applications using the Identity Directory for storing identities and assignments. Identity Authentication can also determine how to federate authentication and merge relevant attributes into tokens for the SAP landscape.

Read about the reference architecture for Cloud leading identity lifecycle authorizations on SAP Architecture Center.

The figure shows the process of identity authentication used as a broker.

Identity Authentication terminates the authentication flow and creates a new token for the application. Identity Authentication supports Resource Provider and Service Provider initiated SAML2.0 and OpenID Connect (OIDC) flows. Identity Provider initiated SAML2.0 is supported but not recommended because it reduces control over authentication, complicates security policy enforcement, and hinders effective federation management.

Identity Directory stores user identities and assignments, enabling attribute merging into application tokens.

To enable Single Sign-On (SSO) for SAP GUI applications, it's recommended to use Secure Login Service (SLS), a cloud-based service that uses X.509 certificates instead of SAML2.0 or OIDC flows.

The figure shows the SSO based on X.509 certificates in SAP Secure Login Service for SAP GUI​.

Here's how it works:

1. The user activates SSO in SAP GUI and logs in through the Identity Authentication Service (IAS).
2. IAS generates an OIDC token containing user attributes from its directory or a third-party identity provider (IdP) and sends it to SLS.
3. SLS creates a short-term X.509 certificate for the user, stores it in the SAP GUI certificate store, and the SAP GUI uses this certificate to access the SAP application.

SLS ensures secure authentication and SSO with digital certificates, eliminating the need for additional on-premises servers. It works seamlessly with identity providers like Microsoft Entra ID or Okta, supporting features like multifactor or biometric authentication. This setup provides a consistent and simplified user experience across all platforms, improving usability and reducing complexity.

In many cases, applications need information from other systems to perform tasks. These service-to-service calls can either propagate the logged-in user's identity or not. For example, when a user manages tasks in SAP Task Center, the service needs to call target applications on behalf of the user to apply authorizations and log actions as if the user were directly in the target application.

The figure shows the integration of SAP Task Center service-to-service.

To ensure secure communication of the user's identity and authorizations, OAuth is typically used. The calling system acts as the OAuth client, and the target system is the OAuth resource server. The OAuth client must present a valid access token, obtained from the OAuth authorization server that may be part of SAP Cloud Identity Services or the target system itself.

The identities of both the OAuth client and the user must be verified before obtaining the access token. This can involve sending a SAML bearer assertion or OIDC identity token as part of an OAuth grant flow. To obtain these tokens, the calling system exchanges the original user authentication token with SAP Cloud Identity Services or a corporate identity provider, especially for third-party integrations.