Customizing the Login process

The Identity Authentication service 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

The Identity Authentication service 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

The Identity Authentication service provides the following enterprise features:

• Branding of end user UIs
• Password and privacy policies

The Identity Authentication service is interoperable with all application supporting SAML* 2.0 standard or OpenID Connect (OIDC).

The Identity Authentication service has the following IdP proxy features:

• Authentication that 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

The Identity Authentication service 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 Identity Authentication product features can be used, including UI configuration policies and two-factor authentication

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

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

As a proxy to multiple IdPs, the Identity Authentication service 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 the Identity Authentication service is required

The Identity Authentication service provides convenient user self-service that includes the following features:

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

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

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

The Identity Authentication service 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

A one-time password (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).

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 (which 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.