Tailoring the Login Process

After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Use management functions
  • Explore multi-factor authentication

Identity Authentication


We will now examine authentication and single sign-on for users in the cloud.

The Identity Authentication Service provides you with controlled cloud-based access to business processes, applications, and data. It simplifies your user experience through authentication mechanisms, single sign-on, on-premise integration, and convenient self-service options.

Choose one of the supported authentication methods to control access to your application, like Form, SPNEGO, Social, or two-factor authentication. Use SAML 2.0 protocol to provide single sign-on. Integrate your application programmatically using authentication using API.

Configure Risk-Based Authentication

Help enforce two-factor authentication based on IP ranges, user groups, user type, or authentication method to manage access to a business application.

Delegate Authentication

Delegate authentication to a third-party or on-premise IdP, as default or based on a condition like IdP, e-mail domain, user type or user group, and thus enable SSO across on-premise and the cloud.


Use SCIM REST API to manage users and groups, invite users, customize end-user UI texts in any language.

SAP Business Transformation Platform Identity Authentication Service (IAS)

SAP Business Transformation Platform IAS provides simple and secure access to Web based applications with a variety of authentication methods at anytime and from anywhere. The service was previously know as SAP Cloud ID service.

Authentication and Single Sign-On in the Cloud

IAS provides secure and simple access based on the following factors:

  • Identity federation based on SAML 2.0.
  • Web Single Sign-On SSO and desktop SSO.
  • Secure on-premise integration to reuse existing authentication systems.
  • Social login and two-factor authentication.
  • Risk-based authentication.

IAS provides user and access management based on the following factors:

  • User administration and integration with on-premise user stores.
  • User groups and application access management.
  • User self-service, for example, password reset, registration, and user profile maintenance.
  • System for Cross-domain Identity Management (SCIM) API.

IAS provides the following enterprise features:

  • Branding of end user UIs.
  • Password and privacy policies.

Open Security Standards

IAS is interoperable with all application supporting SAML* 2.0 standard or OpenID Connect (OIDC).

Delegated Authentication IAS as a Proxy to a Corporate Identity Provider (IdP)

IAS has the following IdP proxy features:

  • Authentication is delegated to corporate IdP login.
  • Reuse of existing SSO infrastructure.
  • Easy and secure authentication for employee scenarios.
  • Federation based on the SAML 2.0 standard.

Delegated Authentication - Authentication with an On-Premise User Store

IAS can connect to an on-premise user store.

  • Users credentials are taken from:
    • Active Directory (through LDAP).
    • AS Java (which can be either local UME, ABAP store or AD).
  • There is no user replication required to the Cloud.
  • Internal network ports do not need to be exposed to the Internet.
  • Other IAS product features can be used including UI configuration policies and two-factor authentication.

Delegated Authentication Re-use of Windows Domain Authentication (SPNEGO)

SPNEGO authentication provides the following:

  • Users authenticated with Microsoft Active Directory can utilize SSO for Cloud applications without re-authentication.
  • Reuse of existing corporate identity infrastructure.
  • Secure authentication and SSO for Cloud and on-premise Web applications.

Delegated Authentication Conditional Authentication

Depending on several factors, different types of users can be re-rerouted to different IDPs for authentication.

As a proxy to multiple IdPs, IAS provides:

  • A secure business network and allows partner users to login via their corporate IdP.
  • Authentication that is initiated by the corporate IdP.
  • An optional check for correct user group assignment can be configured upon successful authentication; a sync of users from IdPs to groups in IAS is required.

User Creation Sources

Branding and Customization

User Self-Services

IAS provides convenient user self-service that includes the following features:

  • Self-registration
  • Account confirmation via email
  • Forgotten password reset
  • Edit of account details or password change
  • Activation of 2-factor authentication
  • Linking or unlinking of social accounts

Access Protection for Applications

The following access protection is provided for applications:

  • Protecting the registration to applications from spam and abuse
  • Preventing bots from automated fake user registrations to your applications
  • Google reCAPTCHA and phone verification provide further protection through self-registration

Logon Overlays in Customer Applications

The customer application logon screen can be programmed to integrate with the application. It has out-of-the-box integration with SAP Cloud portal.

Authentication Options

IAS provides the following authentication features:

  • Basic authentication
  • Based on user ID/email and password
  • Re-use of Windows domain logon
  • Kerberos token used for SSO
  • Two-factor authentication
  • Second factor authenticated on mobile device
  • Delegated logon i. Social IdPs ii. Corporate IdP

Two-Factor Authentication with SAP Authenticator

OTP is required for login in addition to the password or security token. The second factor authentication is used in high security scenarios.

The SAP Authenticator mobile app creates a One-time Password (6-digit) on a mobile device. It is available for iOS and Android and is RFC 6238 compatible (with authenticator apps from Google and Microsoft).

Control Access to the Application

Custom Password Policy Configuration


OAuth Authorization Flow

The OAuth authorization process is as follows:

  1. The resource owner makes a call to protected resources using the OAuth 2.0 client.
  2. The OAuth 2.0 client doesn't have an access token for the target system and redirects the browser to the authorization endpoint of the authorization server. This redirection is called authorization code request. At the authorization server, the resource owner is authenticated and can further restrict access or grant access to the preselected scopes.
  3. The authorization server sends the authorization code back to the OAuth 2.0 client by redirecting the resource owner's user agent back to the redirection URI (that was defined during OAuth 2.0 client registration).
  4. The OAuth 2.0 client sends an access token request to the authorization server's token endpoint. This access token request contains the authorization code.
  5. The authorization server receives the access token request at its token endpoint and validates the authorization code. After a successful validation, the authorization server returns an access token to the OAuth 2.0 client.
  6. The OAuth 2.0 client uses the access token to request resources.
  7. The resource server grants the OAuth 2.0 client access to protected resources in accordance with the access token.

Log in to track your progress & complete quizzes