SAP Identity Authentication Service (IAS) | Overview and Integration Capabilities

Preventing unauthorized access is an important aspect of most enterprise applications, particularly with regard to hybrid SAP landscapes that utilize both on-premise and cloud tools. 

In these cases, a centralized authentication approach can streamline authorization management. After all, an organization may use multiple cloud services (SAP’s cloud solutions are just a few of many), a fact which can result in numerous login requirements. Without putting proper single sign-on (SSO) techniques into place, this would cause a significant burden for everyone involved. 

One thing is clear: without proper identity access management (IAM) solutions in place, things could get messy very quickly.

The purpose of IAM is to provide an array of security functions in the cloud environment that include authentication, authorization and provisioning (among others). It can thereby automate access rights management, and helps to make sure the correct people with the right privileges are accessing either the cloud or local resources.  

This blog will focus on the topic of secure authentication, and in particular on the SAP Cloud Platform Identity Authentication Service (IAS), providing an overview of its core services, features and integration capabilities. 

AUTHENTICATION CHALLENGES IN A HYBRID SAP APPLICATION LANDSCAPE

Before we take a closer look at IAS, let’s begin with some basics. Choosing the right authentication solution should be one of the top agenda items for organizations that want to provide secure access to cloud applications. 

User identities are the foundation of a stable and secure access control system. All access to data and resources is controlled through this system, so it’s far from trivial. Rather, it should be seen as central to ensuring security in this permanently-exposed application landscape. 

This is best accomplished with an underlying platform, such as Azure from Microsoft or the SAP Cloud Platform (SCP). Both enable the centralization of user identities, facilitate a connection to existing user stores, and provide various options for integrating with on-premise resources such as access governance, identity management, and/or provisioning functions.

Most organizations operate a hybrid landscape, with lots of standard SAP applications as well as custom-developed software running both in the cloud and on-premise. 

In cases like these, you want to prevent your employees from having to constantly enter different User IDs and passwords to access various applications by providing simple but secure access via single sign-on. 

With frequent cloud use, technologies such as SAML, OpenID Connect/OAuth, and SCIM become even more important when it comes to authenticating or managing identities. 

This offers added value from the perspective of IT security — especially concerning the possibilities for access management and access governance — because end-users cannot bypass the secure central authentication instance. Instead, they first need to get a valid SAML token to be able to access their cloud or on-premise applications.

SAP CLOUD PLATFORM AND IDENTITY AUTHENTICATION

Some cloud applications don’t even have standalone user management built-in, and no longer accept password-based authentication. Instead, these applications outsource their user-management and authentication processes to a central system for obtaining the security token required for access. This allows centralization, simplified user provisioning, and simplified administration.

One example is the SAP Cloud Platform (SCP) itself, which does not provide a user database of its own. By default, every account is connected to the SAP ID Service (for initial access of admin staff performing tasks on the global and subaccount), which is known as the concept of the platform identity provider. 

For the integration, you can set up a trust relationship between your SCP subaccount and your SAP Identity Authentication tenant. As a result, when you deploy an application to SCP that has protected resources and requires SAML authentication, the user is redirected to the logon page of your SAP IAS to provide credentials. 

In this scenario, the SCP acts as a service provider, and SAP IAS service acts as the so-called application identity provider in this setup. The configurations made in the administration console do not affect the authentication for the cockpit, which is carried out via the standard SAP ID service.

Within SCP, you can provide services and applications such as Java, HTML5, HANA XS, and many more. Organizations require appropriate permissions (roles) to restrict access to these services. As a consequence, the applications running on SCP must be able to understand various user attributes. It’s important to define how the required user attributes, sent by the identity provider (so-called assertion attributes or claims), are mapped to the user attributes consumed by applications on SCP. 

Authentication is one piece of the puzzle. Once logged in, authorizations (or roles) determine what a user can do. So you need some degree of mapping that utilizes attributes both sides understand. As such, the authorization concept (a.k.a. SAML group to SCP role mapping) is very important and, in this case, can be an element of the SAML authentication process. 

Of course, cloud-exposed business applications are consumed not only by employees (end-users), but also by partners and customers that require access to specific applications. Thus, modern organizations increasingly face the challenge of managing secure access and authorizations in both cloud and on-premise systems — even in business-to-consumer (B2C) or business-to-business (B2B) scenarios. 

Furthermore, many organizations prefer using their already-established authentication systems and policies, which in turn are often cloud services as well (such as Microsoft Azure). They want to decide how to authenticate an identity at the IdP for a given application, as well as which conditions, risks, and/or rules should be evaluated during the authentication process. And yes, as you may have guessed: even this is possible in conjunction with SAP Identity Authentication.

Because of its incredible flexibility, and due to the fact that the SAP Cloud Platform Identity Authentication service is considered as the “one integration point” to all SAP cloud applications, there’s good reason to take a closer look at this solution. 

OVERVIEW AND POSITIONING IN THE SAP CLOUD PORTFOLIO

SAP Cloud Platform Identity Authentication runs on top of the SAP Cloud Platform and can be seen as a cloud service for secure authentication. It was introduced in 2014 and, for quite a while, SAP positioned Identity Authentication as a strategic central service for authentication to SAP and non-SAP cloud applications supporting B2C, B2B, and B2E scenarios. It provides Web SSO based on SAML 2.0 and OpenID Connect.

Even though SAP Cloud Platform Identity Authentication is offered as a stand-alone service supported for both the Neo and Cloud Foundry environments, it primarily operates in tight integration with SAP Cloud Platform. 

Additionally, it comes pre-integrated as part of many SAP cloud solutions, including SAP S/4HANA Public Cloud, SAP SuccessFactors, SAP Cloud Portal, SAP Integrated Business Planning, SAP Hybris and SAP JAM (just to name a few). If you have one of these applications, you probably already have a tenant for IAS without knowing it. 

Plus, that list of pre-bundled SAP solutions will grow significantly in the upcoming months. This provides the advantage that SAP can provision ready-to-use applications that are pre-configured with IAS. Consequently, customers have one integration point for their SAP cloud applications, which also helps to reduce overall complexity and administrative efforts during the onboarding of future applications.  

SAP Cloud Platform Identity Authentication service is a multi-tenant system where tenants share the hardware and software and use dedicated database instances for persistence. Features such as high availability, disaster recovery, and failover are based on the capabilities of the underlying SCP infrastructure. 

SAP provides one Identity Authentication tenant per customer, regardless of the number of contracts signed in which Identity Authentication is included or bundled. You can request a second tenant (for testing purposes) which is provided upon request for no additional cost.

Identity Authentication is the central interface that implements flexible authentication scenarios for employees, customers and partners, and bundles access to connected SAP or non-SAP cloud or on-premise applications across almost any device. 

The solution offers the following key features:

• Standardized methods for authentication.
• Flexible integration scenarios (e.g., with existing corporate or social IdPs).
• Common user experience.
• Centralized administration.
• Additional security features for protecting access to applications.
• Risk-based authentication rules and two-factor authentication.
• Delegated authentication to both on-premise user stores and existing identity providers (such as Azure and ADFS).

Through all of the above, it simplifies the user experience by supporting secure single sign-on, on-premise integration, and convenient self-service and user provisioning capabilities.

In combination with the SAP Cloud Platform Identity Provisioning, the two solutions provide capabilities for user authentication and provisioning, which is an important requirement for all modern integration or extension scenarios. Both solutions form the core of the central IAM cloud services. 

Contrary to the previous term — SAP Cloud Platform Identity and Access  Management (IAM) services — the newest umbrella term for these services is SAP Cloud Identity Services. More components are being planned in the future. You can learn more about SAP’s future plans in this blog post from SAP.

One thing that’s important to understand is that SAP Identity Authentication does not persist any application context information, or evaluate exact user behavior within specific applications. Its job is to provide security tokens to authenticated principals for given target applications. 

If you want the ability to take a deeper look into the rabbit hole — and require in-depth analysis options, access request processes, segregation of duty checks, and firefighter functionality across the hybrid landscape — check out this blog post from Alessandro Banzer about the SAP Cloud IAG. 

SAP Cloud Internet Access Governance (SAP Cloud IAG) plays an important role in achieving access governance. 

Considered together, these three services integrate to provide a holistic solution to common identity and access management challenges SAP organizations are faced with.

FEATURE OVERVIEW

• Secure authentication for cloud and on-premise service provider applications
  (includes Non-SAP and third-party software as well).
• Delegated authentication through integration with on-premise user stores and corporate identity providers including SAML 2.0 identity federation.
• Flexible authentication options and password policies.
• Single sign-on functionality from anywhere to any device.
• Social login through Twitter, LinkedIn, Facebook and Google.
• Two-factor authentication based on one-time passwords.
• Risk-based authentication based on various conditions such as application, user groups, IP-ranges and domains.
• Customizable look-and-feel features, such as company branding or authentication overlays.
• Invitation workflows (e-mail) including self-services with customizable self-registration forms and password reset.
• Support for managed identity lifecycle via IDM solutions.
• SCIM REST APIs to manage users and groups, invite users, and customize end-user UI texts in any language.
• Setup of custom privacy policies and terms of use on an application-by-application basis.
• Usage reporting and monitoring capabilities.

OPTIONS FOR USER MANAGEMENT

In the first step, it’s important to consider how user management should be conducted. Since IAS acts as the central IdP for all connected applications, the users have to authenticate at the IAS first. In order to do that, they need to have a user (a.k.a. profile) there. 

In general, an organization using SAP Identity Authentication has the following options:

1. USE THE LOCAL USER STORE IN IAS (DEFAULT)

First is the manual user creation process within the Identity Authentication web admin console. There, the administrators can also bulk import new users or update data for existing users via CSV upload. You can also invite users for self-service profile creation. 

Indeed, the most exciting feature is automation through SCIM. The management of user-profiles (Create, Update, Delete) as well as groups in the IAS user store, can be fully automated with practically any SCIM-compatible system, including Azure or third-party IAM or IDP-solutions/connectors. 

If you connect your existing SAP IDM 8.0 via the Identity Provisioning Service (IPS) with IAS, you can even create users based on provisioning requests by assigning business-roles containing access to cloud applications.

2. CONNECT TO AN EXISTING USER REPOSITORY

If you have an existing on-premise user store, you can configure Identity Authentication to use the corporate user store in addition to its own cloud user store. In this case, you connect an existing on-premise user store, which can be either an LDAP (Active Directory) or SAP system (like HCM). When you do, IAS checks the credentials against this user store in order to authenticate the user. This is done by tunneling IAS via the SCP connectivity service and the SAP Cloud Connector to your on-premise system.

After the first successful authentication, a partial user record (including user details taken from the corporate user store) is created in the IAS user store. This allows for additional features like enabling two-factor authentication or defining user groups which can be considered within custom IAS risk-based authentication rules.

3. INTEGRATE WITH AN EXISTING IDENTITY PROVIDER

The third option is to integrate with another SAML IdP. Often, customers already operate a corporate IdP, which can be any third-party SAML 2.0 IdP. In such a case, you can implement IAS in proxy mode, forwarding the authentication requests to the desired authenticating IdP. 

When operating IAS in this mode, only one trust exchange between IAS and your corporate IdP is required. Trusts to all further applications are configured by IAS admins without involving further corporate IT resources. 

As a result, you only need to perform the configuration for the corporate authentication mechanisms to your corporate IdP once. After that, all future applications can make use of it. In this setup, you don’t need to create a profile in the IAS user store at all, because your IdP forwards the SAML token (including the desired claims) to IAS, which in turn uses them to issue the actual SAML token for the target application. 

You can see IAS as an authentication hub, transforming and forwarding authentication tokens to different target applications. 

Recent experiences in customer projects have shown that it makes perfect sense to have a local user in the IAS. Due to the fact that IAS is able to enrich SAML assertion attributes coming from the corporate IdP, this gives you much greater flexibility when it comes to supporting different applications with their Name ID format requirements (such as Ariba) or for providing custom SAML claims to the applications if they are not delivered by the corporate IdP at all. Of course, a combination of all three mentioned options is possible.

AUTHENTICATION AND SAP Single Sign-On (SSO)

1. USER TO IAS

Once you have your users in IAS, you can select from a variety of different authentication mechanisms including Single Sign-On (SSO). Of course, users can still log on with their username and password, but that is just one possible authentication method.

Let’s have a look at what is currently possible:

• HTTP form-based authentication: Basic authentication with username and password.
• Certificate-based authentication: Use your existing X.509 certificates and PKI for user authentication.
• Simple and Protected GSS-API Negotiation Mechanism (SPNEGO): Allows users to log on without a username and password when they are in the corporate network (which integrates your Active Directory domain to IAS).
• Multi-factor authentication: You can use one-time passcodes from the SAP authenticator app or SMS as a second factor. The latter requires an account in SAP Authentication 365.
• A custom RADIUS server: July 2020 beta feature – only available upon request.
• Delegated authentication: Means forwarding all authentication requests to a corporate Identity Provider by using the SP-component of IAS acting as the IdP-Proxy.
• Social authentication: Reuse your account at Twitter, Facebook, LinkedIn or Google – often used for external in B2B or B2C scenarios.

2. USER TO APPLICATION

In a second step, if the user is successfully authenticated at the IAS based on custom policies and rules, they receive the required security token for accessing the target cloud or on-premise application, which can be one of the two:

• SAML 2.0 assertion
• OpenID Connect (OIDC) JSON Web Token

In addition to SAML 2.0, you can use SAP Cloud Platform Identity Authentication service to authenticate users in OpenID Connect (OIDC) protected applications. OIDC is a simple identity layer on top of the OAuth 2.0 protocol. Clients can verify the identity of the end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. The OIDC implementation of IAS supports the authorization code flow, the resource owner password credentials flow, and the implicit flow.

FREQUENTLY ASKED QUESTIONS

CONCLUSION

As you can see, the SAP Cloud Platform Identity Authentication service provides a range of interesting functions that a traditional on-premise IdP cannot offer. In our next blog post about SAP Identity Authentication, we will take a closer look at what’s possible when operating IAS in “proxy mode” in conjunction with Azure Active Directory. 

Learn more about SAP Cloud Platform Identity Authentication:

• SAP Cloud Identity Services community page
• SAP Identity Authentication product page 
• Further Integration scenarios
• SAP Help Portal

• Author
• Recent Posts

Carsten Olt

Managing SAP Security Consultant | SAP Trainer Secure Authentication | SSO | Cloud Security Services at Xiting GmbH

Carsten Olt has been working as a Managing SAP Security Consultant since 2016, responsible for Secure Authentication & SSO and SAP Cloud Security Services at Xiting in Germany. As a member of the IAM team, he is also a team leader who conveys the company's goals and strategies to employees and has organizational responsibility.

With a security-minded approach, Carsten has international project and IT security experience in many industries. He has been working in IT-Security since 2001, specializing in SAP security since 2010. He is a subject matter expert for SAP Single Sign-On 3.0 and a trainer for the WDESSO course. His current focus is on supporting customers in solving authentication and security challenges within hybrid SAP landscapes, as well as designing and implementing holistic authentication concepts. Carsten is an ISACA CISA and a former MCP and RHCE with an ISP background, and he looks at security from different angles. He also translates between SAP and IT security vocabulary.

Carsten has in-depth experience in multi-vendor architectures and MSFT/Azure components, dealing with all the requirements concerning SAML 2.0, OAuth, OpenID Connect, SCIM, X.509 CBA & PKI, MFA, SAP SSO, and Secure Network Communications, Kerberos/SPNEGO, data security and encryption, as well as digital signatures.

Carsten is experienced in SAP on-premises components such as S/4HANA, ABAP, and Java, as well as security solutions like SSO 3.0. Since 2019, he has focused on SAP-Cloudified environments, specifically the SAP Cloud Identity Services and SAP BTP, as well as SaaS integrations concerning IAM. He deals with hybrid SAP security in conjunction with Azure Active Directory, ADDS, ADFS, ADCS, Reverse Proxies/WAF, SAP Web Dispatcher, SAP Cloud Connector, third-party products, and infrastructure components.

Latest posts by Carsten Olt (see all)

• Cloud Integration Made Easy: Xiting Central Workflows (XCW) Meets SAP Cloud - 30. July 2024
• From Nostalgia to Excitement: The Impending End of SAP IDM - 15. March 2024
• 2024 SAP Cloud Identity Services & IAM Portfolio: What’s New? - 23. February 2024