CIO Guide: Identity Lifecycle in Hybrid Landscapes - sap.com€¦ · 6 / 52 To explain how IAM software from SAP supports you in fulfilling the requirements related to system integration

Hybrid Landscapes

CIO Guide: Identity Lifecycle in Hybrid LandscapesWith a Focus on Identity and Access Management Services

© 2

018

SAP

SE o

r an

SAP

affilia

te c

ompa

ny. A

ll rig

hts

rese

rved

.

1 / 52

2 / 52

3 Executive Summary

5 Introduction

8 IdentityLifecycle

11 OverviewofIAMSoftwarefromSAP11 SAP Cloud Platform Identity

Authentication Service13 SAP Cloud Platform Identity

Provisioning Service14 Support for Identity and

Access Management15 SAP Cloud Identity Access

Governance

16 ReferenceArchitectureforIdentity andAccessManagement

22 ScenariosforIdentityand AccessManagement

22 B2E: Employees Working in a Hybrid Landscape

25 B2C: Customer Identity and Access Management

26 Business to Business (B2B)26 On-Premise Products for IAM and GRC

31 StandardsforAuthentication andProvisioning

31 Security Assertion Markup Language34 OpenID Connect35 System for Cross-Domain Identity

Management36 Standards as the Foundation of the

Target IAM Approach from SAP

39 SSOwithSAPCloudPlatform IdentityAuthentication

42 Third-Party Cloud Identity Providers

43 SpecialCase:Service-to-ServiceCalls43 Single Sign-On for Service-to-Service

Calls44 OAuth SAML Bearer Flow48 Security Information and Event

Management50 Outlook

52 FindOutMore52 Product-Related Links 52 Standards

Table of Contents

© 2018 SAP SE or an SAP affiliate company. All rights reserved.

3 / 52

Executive Summary

In the context of the identity lifecycle, IAM software from SAP contributes to seamless system integration, regardless of how heteroge-neous a system landscape is. Cloud and hybrid environments are in focus because customers are transforming their businesses by moving to the cloud. In this transformation process, hybrid environments consisting of cloud and on-premise components are very common in customer software landscapes, either as a tran-sition step or a purposeful business strategy. In addition, the number of different technologies on which SAP® software runs is constantly grow-ing, both through SAP’s own developments and through acquisitions.

Customers maintain their users in cloud or on-premise user stores, which are often third-party products. In the face of such heterogeneous setups, customers expect SAP to provide them with an integrated approach to solving the chal-lenges that identity and access management poses. They expect to be able to have the right user data in the right software systems at the right time. Moreover, they want their users to enjoy a full single-sign-on experience, facing as

few logon screens as possible. At the same time, a sound IAM solution is expected to ensure that security-related rules, compliance with policies, and legal requirements are successfully observed.

This guide describes IAM software from SAP. It also discusses the planned approach cloud solutions from SAP will follow to align with the overall goal of making system integration easier and successful. The principles of this approach are based on well-accepted industry standards, including Security Assertion Markup Language (SAML), OpenID Connect (OIDC), and System for Cross-Domain Identity Management (SCIM).

Most SAP customers have an IAM solution in place. Those wishing to continue deploying their existing IAM system infrastructure need only integrate with IAM software from SAP once to consume the services that cloud solutions from SAP provide. In such a setup, IAM software acts as a facade; customers do not have to integrate with each SAP application separately. SAP also supports customers who want to continue using their third-party or legacy components, for example, as a central user store.

This CIO guide is about SAP’s approach to identity and access management (IAM) in the context of the identity lifecycle. It explains how IAM software from SAP supports building successful system integrations in cloud and hybrid environments, with diagrams and a reference architecture included to illustrate. By using well-established IAM-related industry standards, SAP improves system integration and helps provide a seamless user experience while also helping to ensure security and compliance.


This guide explains the identity lifecycle and mentions the SAP offerings for each area. A reference architecture diagram shows the major components of IAM, and further diagrams illustrate the different setups discussed. Besides the basic scenarios “business to employee” and “business to consumer,” this guide discusses single sign-on (SSO) with the SAP Cloud Platform Identity Authentication service, SSO for service-to-service calls, as well as security information and event management.

Clearly, no IAM solution is complete without governance, risk, and compliance (GRC) support; however, we refer only briefly to SAP GRC solutions.1 In the area of privacy and consent management, the SAP Hybris® portfolio currently includes three new solutions from Gigya, now a part of SAP, that address compliance with the EU’s General Data Protection Regulation (GDPR). And SAP constantly works on improving its offerings in areas related to IAM, which will lead to future enhancements. The section “Outlook” discusses these forward-looking topics.

4 / 52

Most SAP customers have an IAM solution in place. Those wishing to continue deploying their existing IAM system infrastructure need only integrate with IAM software from SAP once to consume the services that cloud solutions from SAP provide.

1. Refer to “CIO Guide: Process and Data Integration in Hybrid Landscapes.”


5 / 52

Identity and access management defines the identity of users, manages what they can and cannot do, and provides compliance audits and reports on this information. To support these tasks, an IAM software solution is expected to provide the capability to create and manage user accounts, roles, and access rights for individual users in an organization. The solution typically incorporates user provisioning, password man-agement, policy management, and identity repositories.

As more companies move to the cloud, their IT landscapes are becoming more heterogeneous and diverse, often resulting in coexisting cloud and on-premise software systems – so-called hybrid environments. But, independently of whether customers are dealing with cloud or hybrid environments, the requirements related to identity and access management remain the same. Customers want to spend minimal effort integrating systems and, at the same time, want to grant their users a seamless single-sign-on experience across systems while ensuring that system and data access are secure.

IAM manages the interaction between different users who have different roles and between the systems that make up a company’s IT landscape. When user interaction works smoothly, system integration is considered to be successful. Ideally, all systems in the IT landscape will behave as one from the user perspective, meaning that users will not have to authenticate themselves repeat-edly when system boundaries are crossed.

Equally important aspects of IAM are security and compliance. A sound IAM solution must ensure that legal requirements are fulfilled and company policies are applied. Furthermore, IAM must make sure that user authorizations are handled correctly so that users with a specific role are allowed to use precisely the services they are entitled to use. The same goes for data: IAM must ensure that the right individuals get access to the right data.

IAM manages the interaction between different users who have different roles and between the systems that make up a company’s IT landscape. When user interaction works smoothly, system integration is considered to be successful.

Introduction


6 / 52

To explain how IAM software from SAP supports you in fulfilling the requirements related to system integration and security, we structured this document as follows:

• “Identity Lifecycle” gives an overview of the main tasks an IAM solution has to perform throughout the identity lifecycle. It starts the moment a relationship between an individual (user) and the organization is established and continues as long as the relationship exists. This includes accounting for possible changes, for example, changes affecting the user’s role. The lifecycle ends when the relationship between the individual and the company ends. At that point, certain steps become necessary to reflect this event.

• “Overview of IAM Software from SAP” describes the capabilities of SAP software products in the IAM area, for example, the SAP Cloud Platform Identity Authentication and the SAP Cloud Platform Identity Provisioning services. It also explains some of the terms used in the document, including identity and access management services.

• “Reference Architecture for Identity and Access Management” provides an overview of the possible components that make up an IAM setup and explains how these components interact across system boundaries.

• “Scenarios for Identity and Access Manage-ment” describes the main scenarios “business to employee” and “business to consumer.” Each scenario description is supported with a diagram to help you trace the interactions involved.

• “Standards for Authentication and Provisioning” describes the well-established industry standards (SAML, OIDC, and SCIM), which constitute the basis for SAP’s approach to IAM. This section also presents the overall direction in which cloud solutions from SAP will move regarding service-to-service call scenarios, which are described later in more detail.

IAM software from SAP supports you in fulfilling the requirements related to system integration and security.


7 / 52

• “SSO with SAP Cloud Platform Identity Authentication” explains how cloud solutions from SAP use the SAP Cloud Platform Identity Authentication service to handle authentication and describes what is required to integrate with this service. This section showcases a hybrid setup, in which the SAP Cloud Platform Connectivity service is used to establish communication between on-premise software systems and SAP Cloud Platform Identity Authentication, which then acts as an identity provider proxy.

• “Special Case: Service-to-Service Calls” describes the special scenario of service-to-service calls and the OAuth SAML bearer flow, which is the most common approach to deal with it.

• “Find Out More” presents a collection of links to the referenced sites as well as links to further information.

The SAP Cloud Platform Connectivity service can be used to establish communication between on-premise software systems and SAP Cloud Platform Identity Authentication, which then acts as an identity provider proxy.


Figure1:IdentityLifecycle

Identity Lifecycle

8 / 52

Identity Lifecycle

ProvisioningRelationshipbegins

Relationshipchanges

Relationshipends

Authentication

Authorization

Compliance

Privacy policy and consentmanagement

Deprovisioning

Figure 1 shows a typical identity management lifecycle, including all relevant administrative processes. Let us assume that we are looking at a company that operates a hybrid system landscape with systems both on premise and in the cloud. The cycle starts when the relationship between a user and the enterprise begins. A user can be an employee, a partner, or a customer (or consumer). First of all, a user account is created in the company’s central user store. By means of provisioning, the user data is distributed to all systems relevant for this user. The user’s role is one important factor that determines the subsequent processes and checks that apply.

Aside from providing users with an appropriate account, the system may also offer users a frame in which they can personalize services. Typical examples are language settings and date and time formats. Additionally, the system may trigger workflows for business stakeholders to review and either approve or reject proposed changes to user profiles or access rights. During a person’s relationship with the company, their role and tasks can change, for example, after a promotion or after responsibilities change. Once this happens, the person’s user accounts must be adapted to reflect the change. For example, new user accounts may be needed, existing ones may need to be deactivated, or authorizations may require changes.

Aside from providing users with an appropriate account, the system may offer users a frame in which they can personalize services. Typical examples are language settings and selecting date and time formats.


9 / 52

In the authentication step, the user’s identity is validated and their role is determined. For this purpose, the (cloud) application system where the user needs to work sends the authentication request to the identity provider system. The latter then confirms the user’s identity to the cloud application (provided that the user is known to the identity provider). Once this happens, the cloud application system can carry out the user’s logon. The access rights are established and continually monitored in the authorization step. Once authentication within one system has taken place, authorization specifies the applications the user is entitled to start and use in that system as well as the precise data the user is permitted to access within an application. Also in this step, the system handles procedures for treatment, processing, and accessing private information.

It is at this point that the system performs controls to identify and deal with attempted security breaches. Self-services are established in order to reduce administrative overhead. For example, users may reset passwords by using a self-service.

An essential part of the identity lifecycle is governance, risk, and compliance. Compliance defines how to conform with requirements defined by laws, regulations, and policies. Segre-gation of duties, on the other hand, is one typical case that pertains to governance. There are cer-tain combinations of activities within a system that must not be performed by the same person. For example, the same person must not create an invoice and be able to approve that same invoice.

Once authentication within one system has taken place, authorization defines the applications the user is entitled to start and use in that system as well as the precise data that the user is permitted to access within an application.


10 / 52

One increasingly important aspect of the identity lifecycle is the use of personal data. The privacy policy of a company declares how private and personal information of users is processed. With consent management, users can confirm the personal information they are willing to allow the company to access and use based on preestab-lished conditions. In this context, it is worth mentioning that the GDPR came into force May 2018. The GDPR, which replaces Data Protection Directive 95/46/EC, is designed to harmonize data privacy laws across Europe. Stronger, more uniform rules on data protection mean that citi-zens have more control over their personal data. Businesses worldwide will benefit from having just one set of rules for operating in the EU. This regulation applies to parties who do business in or deal with the personal data of an EU resident when goods or services are offered to them. It also applies to monitoring the behavior of individ-uals within the EU. For more information on the GDPR, consult this Web site.2

Our SAPCloudTrustCentersite has information about security, data protection, and compliance.3 As shown in Figure1, when the relationship between user and enterprise ends, the deprovisioning step takes place, in which the IAM system removes user access to applications and systems.

Figure1 does not depict self-services as part of the identity lifecycle. Self-services refer to certain actions users can take for themselves. For exam-ple, a user may apply for new user accounts and authorization assignments; administrators and key users can set up the corporate branding of their company. Self-services are not discussed in this document, since we assume they exist for every cloud application and central system responsible for authentication, provisioning, and other stages within the identity lifecycle.

2. www.eugdpr.org. 3. www.sap.com/about/cloud-trust-center.html.


http://www.eugdpr.org

http://www.sap.com/about/cloud-trust-center.html



11 / 52

SAP Cloud Platform Identity Authentication provides services for authentication, SSO, user management, and on-premise integration, as well as convenient user self-services such as registration and password reset for employees and partners.

SAP Cloud Platform Identity Authentication and SAP Cloud Platform Identity Provisioning are the core IAM services of SAP Cloud Platform. They cover a large portion of the identity lifecycle. Here we provide only an overview of the capabilities of these two services of SAP Cloud Platform. In addition, since GRC is an essential aspect of any IAM solution, we describe the capabilities of SAP Cloud Identity Access Governance software. For detailed information on these products, links are provided.4 The SAP offerings for on-premise software are mentioned only briefly because our purpose is to emphasize the cloud aspects of hybrid landscapes.

SAPCLOUDPLATFORMIDENTITYAUTHENTICATIONSERVICESAP Cloud Platform Identity Authentication is a product that provides services for authentication, single sign-on (SSO), user management, and on-premise integration. It also provides convenient user self-services such as registration and pass-word reset for employees and partners. While SAP Cloud Platform Identity Authentication has some capabilities to support consumer (or cus-tomer) scenarios, these are now the focus of three new offerings of the SAP Hybris portfolio: the SAP Hybris Consent, SAP Hybris Profile, and SAP Hybris Identity solutions. The identity authentication service provides security features for protecting access to applications, support to define risk-based authentication rules, two-factor authentication, and delegated authentication to on-premise user stores and other identity providers.

Overview of IAM Software from SAP

4. For more information on SAP Cloud Platform Identity Authentication, see https://help.sap.com/viewer /6d6d63354d1242d185ab4830fc04feb1/Cloud/en-US/d17a116432d24470930ebea41977a888.html; for SAP Cloud Platform Identity Provisioning, see https://help.sap.com/viewer/f48e822d6d484fa5ade7dda78b64d9f5/Cloud/en-US /2d2685d469a54a56b886105a06ccdae6.html; and for SAP Cloud Identity Access Governance, see https://help.sap.com /viewer/p/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE.


https://help.sap.com/viewer/6d6d63354d1242d185ab4830fc04feb1/Cloud/en-US/d17a116432d24470930ebea41977a888.html


https://help.sap.com/viewer/f48e822d6d484fa5ade7dda78b64d9f5/Cloud/en-US/2d2685d469a54a56b886105a06ccdae6.html


https://help.sap.com/viewer/p/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE


12 / 52

SAP Cloud Platform Identity Authentication is offered as a stand-alone service. However, being tightly integrated with SAP Cloud Platform, it is also provided as part of it as well as a part of many other cloud solutions from SAP. This estab-lishes it, de facto, as the central authentication hub for customers using both SAP and non-SAP software.

Key features of SAP Cloud Platform Identity Authentication are:

• Secure authentication for cloud and on-premise service provider applications

• Single-sign-on functionality from anywhere on any device (Web and desktop SSO)

• Social login through Twitter, LinkedIn, Facebook, and Google

• Two-factor authentication based on one-time passwords

• Risk-based authentication applied to service provider applications, user group assignment, and Internet protocol ranges

• Easy application onboarding • Support of SAP and third-party software • Password policies on the level of service provider applications

• Customizable look-and-feel features, including support to set up company branding

• Self-services, including self-registration and password reset

• Configurable user registration form • REST APIs for user management • Setup of custom privacy policies and terms of use on the application level

• Usage reporting capabilities • Delegated authentication through integration with on-premise user stores and corporate identity providers

• Identity federation based on SAML 2.05

SAP Cloud Platform Identity Authentication is offered as a stand-alone service. However, being tightly integrated with SAP Cloud Platform, it is also provided as part of it as well as a part of many other cloud solutions from SAP.

5. SAML stands for Security Assertion Markup Language and is a standard for Web-based single-sign-on functionality. For more information, see the section “Security Assertion Markup Language.”


13 / 52

SAPCLOUDPLATFORMIDENTITY PROVISIONINGSERVICEThe SAP Cloud Platform Identity Provisioning service provides easier and secure identity lifecycle management as a service with identity and authorization provisioning and deprovisioning. Key supported features are:

• Automatic creation and management of user accounts

• Management of policy-based authorizations • Ability to deal with on-premise user stores as sources, for example, SAP NetWeaver® Applica-tion Server for ABAP® and Microsoft Active Directory

• Ability to deal with cloud user stores as sources, for example, SAP SuccessFactors® solutions and SAP Cloud Platform Identity Authentication

• Provisioning service optimized for cloud solu-tions from SAP and SCIM-enabled solutions6

• Integration with SAP Cloud Platform Identity Authentication and the SAP Cloud Platform Integration service

• Easier user onboarding • Flexible data transformations • Comprehensive job scheduler for provisioning processes

These features enable customers to set up faster and more efficient administration of user onboarding and offboarding. SAP Cloud Platform Identity Provisioning supports a centralized life-cycle of corporate identities in the cloud. In addition, it can handle automated provisioning of existing on-premise identities to cloud applications.

The SAP Cloud Platform Identity Provisioning service provides easier and secure identity lifecycle management as a service with identity and authorization provisioning and deprovisioning.

6. SCIM stands for System for Cross-Domain Identity Management. This standard is discussed in the section “System for Cross-Domain Identity Management (SCIM).”


14 / 52

SUPPORTFORIDENTITYANDACCESS MANAGEMENTTogether, SAP Cloud Platform Identity Authentication and SAP Cloud Platform Identity Provisioning make up the cloud platform identity and access management services, also referred to as cloud platform IAM. This label is commonly used as an umbrella term to refer to the combi-nation of the identity authentication and identity

provisioning services (see Figure 2). In the architecture models shown later, you will see a more comprehensive term, “identity and access management.” It stands for the whole setup in the cloud, including cloud identity and access management services, connectors, and database (see Figure3).

SAP Cloud Platform Identity Authentication and SAP Cloud Platform Identity Provisioning make up the cloud platform identity and access management services, or cloud platform IAM.

Figure2:CloudPlatformIdentityandAccessManagementServices

SAP® Products

SAP Cloud PlatformIdentity Authenticationservice

SAP Cloud PlatformIdentity Provisioningservice

Cloud platform identity and access

management (IAM) services

Umbrella Term


15 / 52

SAPCLOUDIDENTITYACCESSGOVERNANCESAP Cloud Identity Access Governance software consists of three services: access analysis, role design, and access request. The access analysis service enables you to streamline access with real-time visualizations. It includes an analytics dashboard, where you can select different criteria to set up your analysis. For example, you can select user type, organization, risk type, risk level, and business process. The service lets you refine user assignments to remove or reduce risk. It also provides suggestions for eliminating user roles that are not being used and can propose roles with fewer risks. A mitigation control lets you mitigate any remaining risks related to segregation of duties. Every action you take is recorded and earmarked with a tag that you select yourself, for example, the time period of an audit. The corresponding changes are passed on to the provisioning software.

The role design service supports you in creating, optimizing, and maintaining business roles for on-premise and cloud source systems. It provides integrated processes for designing and managing business roles and helps ensure that users have optimized access assignments.

Development of the access request is ongoing at SAP. It is intended that the service will facilitate the creation of self-service requests to applications in both on-premise and cloud-based systems. The access request service currently offers autoprovisioning and auditable workflows, as well as intuitive access request screens, built-in guides, and data-driven filters.

For more information on SAP Cloud Identity Access Governance, visit this site.7 Additionally, check out our GRCoverviewpage.8 A good entry point for security-related topics is “SAPSecurity,DataProtection,andPrivacy.”9

SAP Cloud Identity Access Governance software consists of three services: access analysis, role design, and access request.

7. https://help.sap.com/viewer/p/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE. 8. www.sap.com/products/financial-management/grc.html. 9. www.sap.com/corporate/en/company/security.html.



http://www.sap.com/products/financial-management/grc.html

https://www.sap.com/corporate/en/company/security.html

https://www.sap.com/corporate/en/company/security.html


http://www.sap.com/products/financial-management/grc.html

http://www.sap.com/corporate/en/company/security.html

16 / 52

Figure 3 depicts the reference architecture of the IAM services from SAP with a focus on SAP Cloud Platform Identity Authentication and SAP Cloud Platform Identity Provisioning (yellow box). To emphasize that these services can deal with cloud and hybrid scenarios, the diagram has been divided into a cloud domain and an on-premise domain. The model displays a

superset of all elements an IAM setup may consist of. A typical customer landscape usually contains a subset of these elements. Additionally, it may include a solution for role design and for resolving issues related to segregation of duties (for example, SAP Cloud Identity Access Governance).

Reference Architecture for Identity and Access Management

Figure3:ReferenceArchitectureforIAMinCloudandHybridEnvironments

Sessiontokens

GRC applications

On premise

HR system

Identity management systems

User interface

Identity provider

Single sign-on

SAP® Cloud Identity Access Governance

Cloud solutions from SAP (examples)HR and collaboration

Planning and analytics

Third-party cloud applications

Azure appsTravel applications

Service providers

Identity providersThird-party corporate IdP

Third-party CIAM

Social platforms

Active Directory Federation Services

Consumer identity and access management

Administration console in

browser

®

® ®

TM


17 / 52

The main (nonhuman) interacting actors in the model are identityproviders,serviceproviders, and the IAM servicessupportedbySAPCloudPlatform. Identity providers are systems that issue user information to service provider systems, vouching for the identity of the users who require access to their services. For this purpose, the identity provider issues a security token that can be accepted as an alternative that eliminates having to repeatedly and explicitly authenticate a user within a security zone. Service providers are systems that offer the business and technical services that users require to do their work. Finally, the IAM services fit into the picture as an identity provider proxy, capable of performing authentication on behalf of third-party providers as well as provisioning (or deprovisioning), particularly, toward the cloud solutions from SAP. More details on the identity provider proxy scenario are given in the next sections.

Identity providers are systems that issue user information to service provider systems, vouching for the identity of the users who require access to their services.


18 / 52

In the tenant-specific administration console, the administrator can use the administration services to select which identity data from which identity provider should be forwarded to which service provider.

10. These are depicted as boxes with a stick figure inside. 11. The term “identity” is sometimes used instead of “user” when talking about a person’s collection of user accounts. At least in

the SAP NetWeaver Application Server for ABAP, the term “identity” also includes business partner information for the user. This guide uses the term “user” to focus on the information that is relevant for authentication and other stations within the identity lifecycle.

12. https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US /e54cc8fbbb571014beb5caaf6aa31280.html. For information on principal propagation using the SAP Cloud Platform Connectivity service, consult www.sap.com/developer/blueprints/finder/cloud-platform-principal-propagation.html.

The human actors in the IAM infrastructure may be administrators or “users.”10 Strictly speaking, the term “user” stands for the technical repre-sentation of a person in the system landscape. Every user has a user account in each system that provides services for the business scenarios that are relevant for that user.11 Users may be employees, consumers, or business partners, with corresponding authorization assignments. A user with an administrator role has access to the tenant-specific administration console in the browser. In the console, the administrator can use the administration services to select which identity data from which identity provider

should be forwarded to which service provider. Furthermore, the administrator sets up the con-nectors in order to establish communication between the identity provisioning service and the service providers. Different connectors are required to establish this communication, de-pending on the peripheral systems that should be connected. For connecting on-premise systems, for example, the SAP Cloud Platform Connectivity service is used.12 In the administration console, administrators configure the necessary trust relationship between the identity provider and the service provider (see the section “Security Assertion Markup Language”).


https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/e54cc8fbbb571014beb5caaf6aa31280.html


http://www.sap.com/developer/blueprints/finder/cloud-platform-principal-propagation.html

19 / 52

For authentication purposes, the user needs a session in the identity provider system that has been chosen to perform this task. Starting from there, user sessions in the requested service provider systems are established as soon as the user starts an application. The session in the identity provider system can be opened either when the user logs on at the beginning of the workday or when the user calls the first application within a service provider. Once the identity provider has issued the authentication, the user sessions in the service provider systems can be established. As depicted in Figure3, SAP S/4HANA® and the SAP Hybris® Cloud for Customer solution are examples of service providers. SAP Ariba® solutions, SAP Concur® solutions, and SAP Cloud Platform are further examples of service providers but are not shown in the figure.

The reference architecture model displays all places where user data is stored. These are shown in pale blue. The following user data is relevant in the context of this document:

• Attributes that serve as a basis for user identification, for example, e-mail addresses and user names

• Attributes used to determine the user’s authorizations. These can specify, for example, the user’s authorization directly (roles, group assignments), or they can be used in the service provider system to derive the user’s authorizations. To illustrate the first group of attributes, you can think of mapping Microsoft Active Directory groups to roles in SAP Hybris Cloud for Customer. In contrast, an example for the second type of attributes could be “country.” This attribute could be used to restrict the data shown to the user, that is, allowing the user to access only the data that belongs to their country.

User sessions in the requested service provider systems are established as soon as the user starts an application.


20 / 52

• Any other attributes that are supposed to be submitted to the service provider. Two submis-sion types can be distinguished: First, attri-butes can be submitted by storing them in the user account of the service provider. In this case, the attributes must be provisioned, such as assignments to roles. Second, attributes can be submitted at runtime as part of the authenti-cation step. In this case, SAML attributes can be used. For example, the information containing the first and last name is submitted by an SAML assertion in order to show “Welcome <first name> <last name>” in a user interface. For more information on SAML, see the section “Security Assertion Markup Language.”

In conclusion, user data is used for authentica-tion and for authorizations (or other purposes) within a service provider. The identity and access

management services handle authentication of users in the service providers and provisioning and deprovisioning of user data.

As stated above, this guide focuses on identity and access management services in the cloud. Various identity providers can coexist in the landscape. They can be services from SAP or third parties. The identity provider chosen to carry out authentication can be one among many, depending on the scenario. Users may be employees whose user data was originally on premise; or users may be consumers whose user data was originally in a cloud identity provider. In a hybrid setup, it is even possible to use and entirely rely on an on-premise identity provider that performs authentication.

In a hybrid setup, it is possible to use and entirely rely on an on-premise identity provider that performs authentication.


21 / 52

As far as the on-premise part of the architecture is concerned, only components that are relevant in the context of IAM are depicted in Figure3. More precisely, no on-premise service provider applications have been considered in the diagram, though they can exist. The on-premise IAM components supported by SAP offerings are well established in the on-premise environment, where they carry out provisioning and authentication as well as GRC-related tasks (see also “On-Premise Products for IAM and GRC”).

“On-Premise Products for IAM and GRC” explains in detail how SAP Cloud Platform Identity Authentication can act as an identity provider proxy. The prerequisite is that all participating systems support the SAML standard. “Single Sign-On for Service-to-Service Calls” explains the additional aspects that must be considered for service-to-service calls. An example of the latter is when a user runs cloud application A, and it calls another cloud application B to retrieve data.

The on-premise IAM components support-ed by SAP offerings are well established in the on-premise environment, where they carry out provisioning and authentication, as well as the GRC-related tasks.


22 / 52

As stated above, the reference architecture for IAM in cloud and hybrid scenarios considers all possible components a customer landscape may consist of. Within a specific customer setup, a subset of these components is usually present. To illustrate such setups, the following sections introduce two main IAM scenarios relevant for cloud and hybrid environments from the perspective of cloud applications. The first scenario deals with employees working with cloud applications – business to employee (B2E). The second describes a similar scenario, but from the viewpoint of customers or consumers – business to consumer (B2C).13

B2E:EMPLOYEESWORKINGINA HYBRIDLANDSCAPEThis scenario describes a common situation in which the employees of a company require services that providers offer either on premise or in the cloud. Since the company assumes the employer role, it ensures user provisioning, meaning that it is responsible for creating the appropriate user accounts and making sure that the employees’ identities are validated and their roles are determined.

A simplified reference architecture for the B2E scenario is shown in Figure4. The blue boxes show the most common options from which a company can choose to locate the identity and access management components. These components provide access to both the user store (not shown in the figure) and identity provider capabilities.

The reference architecture for IAM in cloud and hybrid scenarios considers all possible components a customer landscape may consist of. Within a specific customer setup, usually a subset of these components is present.

Scenarios for Identity and Access Management

13. A further scenario is business to business (B2B), which SAP is currently working on and plans to support in the future. For more information, see the sections “Business to Business (B2B)” and “Outlook.”


23 / 52

Figure4:IdentityandAccessManagementforB2E

Service providers

Identitymanagement

systems

SAP® Cloud Platform Identity Authentication

On premise

Social platforms

IdP: Identity providerCIAM: Consumer identity and access management

Third-party identity providers

Usually, enterprises already have an identity and access management solution in place. Let us assume this applies to you, and you would like to continue using your IAM solution. If you require services from providers in the cloud, you can use the IAM services from SAP (yellow box) to manage the IAM-related integration with the

service providers on the SAP side. In this setup, the IAM services from SAP act as a facade toward cloud solutions from SAP. That means you need to integrate your existing IAM solution only once with the IAM services provided through SAP Cloud Platform.

The IAM services from SAP act as a facade toward cloud solutions from SAP. That means you need to integrate your existing IAM solution only once with the IAM services provided through SAP Cloud Platform.


24 / 52

SAP Cloud Platform Identity Authentication can delegate authentication to any external authenticating authority for any service provider. The prerequisite is that the external identity provider supports SAML 2.0. The identity provider may be cloud based or on premise, SAP or a third party. In other words, the SAP Cloud Platform Identity Authentication service works as an SAML 2.0 identity provider “proxy.” It forwards all requests for authentication sent by a service provider to the registered identity provider, for example, a corporate identity provider such as Azure Active Directory Federation Services, or a social platform such as Google or Facebook. Or it could forward requests to an on-premise identity provider, for example, an HR system (colored in blue in Figure4).

As of today, many SAP customers, especially the large ones, still use an on-premise user store. The alternative is to move the user store to the cloud. The IAM services supported by SAP Cloud Platform can assume the role of the central user store. However, most customers use third-party products such as Microsoft Active Directory (AD) as a user store and Active Directory Federation Service (ADFS) as an identity provider on premise. Or they may use Azure AD and ADFS in the cloud (see Figure3).

Typically, users are created during the hiring process. All data relevant to the user is stored in the user store. For authentication and provisioning purposes, the IAM services use the data from the user store. A reference, such as employee ID, is also contained in the store and supports navigation between user and employee, for example, to provide office-related contact information.

SAP Cloud Platform Identity Authentication can delegate authentication to any external authenticating authority for any service provider.


25 / 52

Figure5:IdentityandAccessManagement forB2C

Third-party identity providers

Service providers

Social platforms


On premise

B2C:CUSTOMERIDENTITYAND ACCESSMANAGEMENTThe B2E scenario described above is where the employer ensures employee user provisioning according to predefined company rules and policies. In contrast, the B2C scenario deals with users who require a more flexible experience across devices and channels in exchange for their data. These users make up a group of customers or consumers.14 Figure 5 shows the relevant differences between the B2C and B2E scenarios (orange boxes).

As you can see, the interactions between customers and the service providers on the SAP side may have their source in social platforms or a dedicated customer IAM (CIAM) identity provider. (In B2E, the employee user interaction with the company starts with the employee’s onboarding.) Customers can choose to sign up, purchase online, or subscribe to digital services. In this CIAM scenario, users have control of their identity, meaning that they decide what kind of information they provide to a business and when. For example, any person-related data such as a delivery address (in case of an online shop) is entered only when the user has purchased something and wants it delivered. Typically, such data is then stored in a master data record. In this example, the master data entity would be “customer.” A corresponding reference supports navigation between the user and the customer data.

The interactions between customers and the service providers on the SAP side may have their source in social platforms or a dedicated CIAM identity provider.

14. For the sake of brevity, we use “customers,” although “consumers” are also meant to be part of this group of users.


26 / 52

Services provided on the SAP side offer a social login for this group of users. Social login works with OIDC,15 with the IAM services of SAP Cloud Platform serving in the role of the relying party. The social login provider – Facebook, Twitter, or Google – serves as the OpenID provider. Customers and consumers can therefore connect to the IAM services of SAP Cloud Platform using their account with one of these providers.

As businesses require more capabilities, especially regarding profile information and reporting, dedicated solutions for CIAM can be used. SAP offers a CIAM solution in the shape of three products: the SAP Hybris Identity, SAP Hybris Consent, and SAP Hybris Profile solutions.16

BUSINESSTOBUSINESS(B2B)Another scenario worth mentioning is business-to-business (B2B) communication. This scenario

focuses on partners accessing and working in applications that belong to the enterprise’s landscape. For this purpose, the IAM services of SAP Cloud Platform provide an option for businesses that lets them invite and register their partners. As the B2B scenario still requires enhancement, it is listed among the topics in “Outlook.”

ON-PREMISEPRODUCTSFORIAMANDGRCOn-premise SAP GRC solutions and IAM solutions are well established and have been providing SAP customers with key capabilities for their on-premise software landscapes for many years. They include support for user account provisioning and deprovisioning to on-premise systems, single-sign-on functionality, and GRC-related capabilities. Figure6 provides an overview of the applications that make up the IAM capabilities and GRC offerings from SAP, mostly in the on-premise domain.

In the B2B scenario, IAM services of SAP Cloud Platform provide an option to businesses that enables them to invite and register their partners.

15. For more information on this standard, see the section “OpenID Connect.”16. For more information on Gigya and the new SAP Hybris solutions, see www.hybris.com/en/downloads/product-collateral /gigya-sap-solutions-trusted-valued-relationships-customers/155.


https://www.hybris.com/en/downloads/product-collateral/gigya-sap-solutions-trusted-valued-relationships-customers/155

https://www.hybris.com/en/downloads/product-collateral/gigya-sap-solutions-trusted-valued-relationships-customers/155

27 / 52

Figure6:OverviewofSAPGRCSolutions

Enterprise risk and compliance

SAP® Process Control

SAP Risk Management

SAP Audit Management

SAP Regulation Management by Greenlight

SAP Business Integrity Screening

SAP Access Control

SAP Cloud Identity AccessGovernance offering

SAP Dynamic AuthorizationManagement by NextLabs

SAP Access ViolationManagement by Greenlight

SAP Identity Management

SAP Single Sign-On

SAP Enterprise ThreatDetection

SAP Enterprise DigitalRights Management byNextLabs

UI field masking

UI logging

Code vulnerability analysis

SAP Fortify by Micro Focus

SAP Global Trade Services(SAP GTS), export management

SAP GTS, import management

SAP GTS, trade preferencemanagement

Special customs procedures

SAP S/4HANA® for international trade

SAP Watch List Screening

Cybersecurity and data protection

International trademanagement

Access governance

Since this document focuses on IAM in cloud and hybrid environments, only a subset of the on-premise SAP software products are described here. We also mention briefly the SAP Access Control application as an essential part of SAP GRC solutions. It goes without saying that the on-premise products contained in the table can

still be part of a hybrid setup. If you are interested in more information about any of these products, we encourage you to visit sap.com,17 where you can search for any product. Detailed product documentation can also be found in our SAPHelpPortalsite.18

On-premise SAP GRC solutions and IAM software from SAP are well established and have been providing SAP customers with key capabilities for their on-premise landscapes for many years.

17. www.sap.com/index.html. 18. https://help.sap.com/viewer/index.


http://www.sap.com/index.html

https://help.sap.com/viewer/index

http://www.sap.com/index.html

https://help.sap.com/viewer/index

28 / 52

SAPIdentityManagementThe SAP Identity Management component (previously named SAP NetWeaver Identity Management) helps companies manage user access to applications securely and efficiently while meeting audit and compliance requirements. The software provides a central mechanism for provisioning users based on their current business roles. It supports related processes, such as password management, self-services, and approval workflows.

SAP Identity Management is designed to work not only with SAP solutions but with all software systems, instances, and applications in a heterogeneous global IT environment. It is also conceived to work as an integrated part of your strategic application platform, delivering identity services to support a service-oriented architecture landscape. Integration with SAP Business Suite applications and the SAP Access Control application results in a true business-driven, compliant identity management solution. Furthermore, SAP Identity Management provides many connectors that enable provisioning of authorization information. For more information, consult the product documentation19 and make sure to check out the communitysite.20

SAP Identity Management is designed to work not only with your SAP applications but with all software systems, instances, and applications in a heterogeneous global IT environment.

19. www.sap.com/products/identity-management.html.20. www.sap.com/community/topic/identity-management.html.


http://www.sap.com/products/identity-management.html


http://www.sap.com/community/topic/identity-management.html


http://www.sap.com/community/topic/identity-management.html

29 / 52

SAPSingleSign-OnThe SAP Single Sign-On application lets companies eliminate multiple passwords and user IDs. With SAP Single Sign-On, companies can lower the risks of unsecured login information, reduce help-desk calls, and help ensure the confidentiality and security of personal and company data. On-premise customers can integrate their central user store with the on-premise SAP Single Sign-On application to obtain the full SSO experience on premise. As indicated above, if they also use the on-premise SAP Identity Management component, they can perform user account provisioning and deprovisioning to on-premise software systems. For more information, consult the product documentation.21 You may also be interested in the related community,22 where you can get your questions answered.

SAP Single Sign-On eliminates the need for multiple passwords and user IDs. This helps companies lower the risks of unsecured login information and ensure the confidentiality and security of personal and company data.

21. www.sap.com/products/single-sign-on.html.22. www.sap.com/community/topic/sso.html.


http://www.sap.com/products/single-sign-on.html


http://www.sap.com/community/topic/sso.html



30 / 52

SAPAccessControlThe SAP Access Control application is an essen-tial component of SAP GRC solutions. By means of its embedded risk analysis capability, it ena-bles you to identify and remediate segregation-of-duty-related issues, as well as critical access violations. With SAP Access Control, you can automate user access assignments across SAP and third-party software. Moreover, you can define and maintain compliant roles in business-friendly terms and language. SAP Access Control carries out periodic user-access reviews and supports you in ensuring that segregation- of-duty-related mitigations are effectively performed on a regular basis. Ultimately, the objective of SAP Access Control is to allow enter-prises to streamline the process of managing and

validating user access to applications and data in an end-to-end fashion. You benefit from a reduc-tion of access risk and the potential for fraud or unauthorized access. The product has been designed to help companies decrease informa-tion management risk and improve the audit trail and transparency. The interplay of SAP Access Control, SAP Identity Management, and SAP Single Sign-On has constituted an effective IAM solution for on-premise customers for many years. In addition, SAP Access Control (from release 12.0) integrates with SAP Cloud Identity Access Governance to let customers connect to cloud applications and bring those applications under the access governance umbrella.23 For more information on SAP Access Control, consult the productdocumentation.24

The interplay of SAP Access Control, SAP Identity Management, and SAP Single Sign-On has con-stituted an effective IAM solution for on-premise customers for many years.

23. https://help.sap.com/viewer/5dc9d8a804e04d47b85ad57abd84bbde/latest/en-US.24. www.sap.com/products/access-control.html.


http://www.sap.com/products/access-control.html

https://help.sap.com/viewer/5dc9d8a804e04d47b85ad57abd84bbde/latest/en-US

http://www.sap.com/products/access-control.html

31 / 52

By using well-established industry standards, SAP improves its system integration capabilities further. For identity and access management in hybrid landscapes, SAP’s purpose is to use and support SAML – and with certain limitations, OIDC – for authentication and SCIM for provi-sioning. In the following sections, we explain each standard separately. The decision to use these standards has resulted in a clear approach in terms of what cloud solutions SAP plans to sup-port to improve system integration.

SECURITYASSERTIONMARKUP LANGUAGEAs far as authentication is concerned, the SAML is a widespread standard for Web-based single- sign-on functionality. It is an XML-based protocol that uses security tokens. The tokens contain assertions that pass information about an end user (or principal) between an identity provider (SAML authority) and a service provider (SAML consumer). The Organization for the Advance-ment of Structured Information Standards

(OASIS) provided the SAML 2.0 specification, which replaced the previous SAML 1.1. Both SAP and its customers use this standard.

The following scenario describes the main elements of SAML. A principal (typically an end user) has a session with an identity provider. When the principal (say, “John Doe”) requests a service from a service provider (any cloud application), the latter initiates a browser redirect to the identity provider. The identity provider then issues an assertion that the service provider uses to authenticate the user and grant him access to the requested service.

The prerequisite for using this standard is that a trust relationship between the identity provider and service provider has been established. The service provider needs to know where to send the authentication requests. This destination is configured as a trusted identity provider, which is the place from which the service provider retrieves the target information for the browser redirect.

The Security Assertion Markup Language is a widespread standard for Web-based single-sign-on functionality. It is an XML-based protocol that uses security tokens.

Standards for Authentication and Provisioning


32 / 52

Further important features that require SAML capabilities are principal propagation and identity federation.25 The former is relevant for applications that call services in other applications and, in doing so, pass on the identity of the end user. Identity federation, on the other hand, is single-sign-on functionality without the need for entering a password. The federation server knows the user’s name in each application or system so that a token is sufficient for the applications or systems to authenticate the user. This, in turn, is possible because of the trust relationship between the federation server and the application or system involved.

A setup using SAML authentication can easily handle heterogeneous systems that use different identifying attributes of users. For example,

while some systems use the e-mail address for the logon (such as [email protected]), others require a user name such as “JDOE.” A configuration in the SAML identity provider supports mapping per service provider. For configuration purposes, certain questions require answers, such as what the identifying attribute of the user is, or to put it in SAML terms, what is the “subject name identifier”? Other attributes the service provider might require could be the user’s country or user’s name. By obtaining this precise information from the user store, no synchronization effort between service provider and identity provider is required. Nevertheless, it may also happen that the information is simply not available on the service provider side.

A setup using SAML authentication can easily handle heterogeneous systems that use different identifying attributes of users. Some systems may use the e-mail address for the logon, but others could require a user name such as “JDOE.”

25. Find more information on principal propagation on SAP Cloud Platform by clicking on this link: www.sap.com/developer/blueprints/finder/cloud-platform-principal-propagation.html.


http://www.sap.com/developer/blueprints/finder/cloud-platform-principal-propagation.html

33 / 52

SAML enables scenarios in which no user storage exists on the service provider side. An example is Cloud Foundry. In such cases, all relevant data is contained in the identity provider. When a service is requested from a service provider, the user information is included in the SAML assertion and used for authentication. The vehicle for this is SAML attributes and SAML groups that are part of the SAML assertion. Authorization- relevant information must be contained in the assertion. In Cloud Foundry, the relevant information is the SAML group assignment for the user in question. Cloud Foundry contains the mapping of SAML groups to Cloud Foundry roles. In other words, when deciding if a user is allowed to start a specific service and access specific data, the SAML group assignment and mapping of SAML groups to Cloud Foundry roles are combined and evaluated.

If SAML assertions contain too much information, performance can suffer. Therefore, it is important to consider the information that will be transported with the SAML assertion.

Approximately 10 attributes or group assignments usually work well, but for many more attributes, other mechanisms should be considered to submit this information. This could be, for example, provisioning of user data to the service provider, or transmission of a handle ID within the SAML assertion, which would require a subsequent service call to retrieve the detail information.

Finally, the ability to use an identity provider in an identity provider proxy role is important for hybrid landscapes. More than one identity provider may exist in a landscape. In addition, they can be from different vendors. As long as they all support SAML and can be part of an identity provider proxy scenario, they can collaborate in authenticating users in hybrid landscapes.

As the identity provider proxy scenario is highly relevant in hybrid scenarios, it is explained separately in the section “SSO with SAP Cloud Platform Identity Authentication.”

The ability to use an identity provider in an identity provider proxy role is important for hybrid landscapes. More than one identity provider may exist in a landscape. In addition, they can be from different vendors.


34 / 52

OPENIDCONNECTOpenID Connect is an open standard that ex-tends the OAuth 2.0 protocol with an identity layer.26 It is promoted by the OpenIDFounda-tion.27 The general idea is that an authorization server verifies the end user’s identity to a client, be it Web based, mobile, or a JavaScript client. The client is called the relying party in the context of OpenID Connect.

To obtain information on the end user’s iden-tity, the relying party contacts the authorization server of the OpenID Connect provider and requests an OAuth token with the scope “openid.”28 The OAuth flow requires both the end user and the relying party (in OAuth terms, the “OAuth client”) to authenticate against the OpenID Connect provider. The end-user

authentication at the OpenID Connect provider is performed, for example, by user name and password, prompted for at the time when the request takes place. In most cases, however, the end user establishes a session with the OpenID Connect provider when they start to work.

The OpenID Connect provider responds to the relying party by issuing an OAuth token containing the grant of scope “openid.” With this token, the relying party can call the user information service of the OpenID Connect provider to obtain all necessary information about the end user. This information makes authentication possible. For more details on the OpenID Connect protocol and the steps that it follows, consult this Web site.29

To obtain information on the end user’s identity, the relying party contacts the authorization server of the OpenID Connect provider and requests an OAuth token with the scope “openid.”

26. OAuth is an open standard for secure access delegation. We also refer to OAuth in “OAuth SAML Bearer Flow.” 27. http://openid.net/foundation.28. The value of the scope parameter is expressed as a list of space-delimited, case-sensitive strings.

See https://tools.ietf.org/html/rfc6749. 29. http://openid.net/specs/openid-connect-core-1_0.html#Terminology.


http://openid.net/foundation


http://openid.net/specs/openid-connect-core-1_0.html#Terminology


https://tools.ietf.org/html/rfc6749

http://openid.net/specs/openid-connect-core-1_0.html#Terminology

35 / 52

It is worth mentioning that, while SAML only supports Web-based scenarios, the OpenID Connect protocol also covers mobile scenarios.

In system landscapes running SAP software, OpenID Connect is used in two scenarios:1. Social media solutions – such as Facebook,

Google, and Twitter – act as OpenID Connect providers. SAPCommunity is one example of this scenario.30 To log on to SAP Community, users can choose to authenticate to the SAP Cloud Platform Identity Authentication service account of SAP Community with their social media user. In this case, SAP Cloud Platform Identity Authentication plays the part of the relying party.

2. SAP Cloud Platform Identity Authentication currently offers selected OpenID Connect provider capabilities to support applications as relying parties. SAP is considering extend-ing OpenID Connect support so that SAP Cloud Platform Identity Authentication can act as a proxy that offers transparent support of both SAML and OpenID Connect.

SYSTEMFORCROSS-DOMAINIDENTITY MANAGEMENTSystem for Cross-Domain Identity Management31 is an open standard for automated exchange of user information in a system landscape. The general idea is to provide a standard format for the usual operations on user accounts, such as retrieval, creation, modification, and deletion. Users are described by certain attributes, attribute schemes, and group memberships. Attributes can contain, for example, contact information, group memberships, and assign-ment to authorization entities.

With the SCIM protocol, a new application can easily be included in the landscape and immediately send or receive user information.

30. www.sap.com/community.html.31. SAP uses SCIM v2, since SCIM v1.1 has some limitations.


http://www.sap.com/community.html


36 / 52

This standardized protocol greatly improves interoperability between the systems containing the user information and the systems that are supposed to receive that information. Without such a protocol, every pair of sending and receiving systems must agree on a mapping of user attributes. For example, in the on-premise SAP Identity Management component, so-called connectors are contained that individually resolve user provisioning for systems based on SAP NetWeaver Application Server for ABAP, SAP NetWeaver Application Server for Java, and others. For every new application, a new connector must be implemented. Consequently, by using the standardized SCIM protocol, a new application can easily be included in the landscape and immediately send or receive user information, as both sides of the communication already understand the information.

STANDARDSASTHEFOUNDATIONOFTHETARGETIAMAPPROACHFROMSAPSAP views IAM as a key aspect for implementing seamless system integrations. Using well-established standards facilitates communication among systems and enables a consistent user experience without compromising security. Therefore, all cloud solutions from SAP will support SAML in the future. They may additionally support OpenID Connect, particularly when it comes to covering mobile scenarios. SAP Cloud Platform Identity Authentication supports both SAML and OpenID Connect. It acts as the identity provider with regard to SAML and as the OpenID Connect provider from the perspective of OpenID Connect. OpenID Connect may become more important than it is today. Should that be the case, SAP will consider extending its support of OpenID Connect in the future.

SAP views IAM as a key aspect for implementing seamless system integrations. Using well- established standards facilitates communication among systems and enables a consistent user experience without compromising security.


37 / 52

For provisioning, many individual connectors already exist. This is especially true for the on-premise SAP Identity Management compo-nent (see the section “On-Premise Products for IAM and GRC”). Some connectors are also avail-able for provisioning through SAP Cloud Platform Identity Provisioning and SAP Cloud Platform Identity Authentication. SAP plans to avoid using connectors and implement the SCIM standard directly. Nevertheless, there are no plans to migrate or replace existing connectors. An advantage of implementing SCIM is indeed that it eliminates the effort of developing individual connectors. A detailed description of the SCIM methods and how attributes are interpreted in SAP Cloud Platform Identity Authentication is available at help.sap.com.32

To facilitate integration, it is planned that all cloud solutions from SAP will support authentication

through SAP Cloud Platform Identity Authentication (see the section “SSO with SAP Cloud Platform Identity Authentication”). For this purpose, the overall plan is to have all cloud solutions from SAP act as SAML service providers. To set up service providers with the SAML identity provider of SAP Cloud Platform Identity Authentication, each has to configure its own trust relationship. For you as an SAP customer, this would mean that you could use SAP Cloud Platform Identity Authentication as an identity provider. However, if you want to use or continue to use a third-party identity provider, you can do so and still work with cloud solutions from SAP (see the section “SSO with SAP Cloud Platform Identity Authentication”). All you need to do is integrate once with SAP Cloud Platform Identity Authentication, and you will be ready to use it as an identity provider proxy.

To use or continue to use a third-party identity provider, you can still work with cloud solutions from SAP. You just need to integrate once with SAP Cloud Platform Identity Authentication to use it as an identity provider proxy.

32. https://help.sap.com/viewer/f48e822d6d484fa5ade7dda78b64d9f5/Cloud/en-US /f217bd39c17d47cdb4f89ed19cb2c701.html.


https://help.sap.com/viewer/f48e822d6d484fa5ade7dda78b64d9f5/Cloud/en-US/f217bd39c17d47cdb4f89ed19cb2c701.html



38 / 52

A special scenario where standards play an important role is service-to-service calls with the OAuth SAML bearer flow.

For the sake of completeness, we mention a special scenario where standards play an important role: service-to-service calls with the OAuth SAML bearer flow. This scenario is discussed in a later section. In the future, SAP plans to include support for service-to-service calls with the OAuth SAML bearer flow in all cloud solutions from SAP. For more details, consult the section “Single Sign-On for Service-to-Service Calls.”

As far as security information and event management (SIEM) is concerned, it is planned that all cloud solutions from SAP will provide an API for push or pull security-related events. For more details, see “Security Information and Event Management.”


39 / 52

In “B2E: Employees Working in a Hybrid Landscape,” we described how a typical hybrid landscape may look and how authentication with single sign-on through SAML works in such a landscape. To enable single sign-on, applications must take certain steps that translate into a future standardized approach for cloud solutions from SAP.

Concerning identity and access management, most customers are using third-party products as a central user store, for example, Microsoft Active Directory. The authentication against this user data repository is performed by a corporate identity provider. If Microsoft Active Directory is being used as the user store, this identity provider is usually Active Directory Federation Services from Microsoft. However, no vendor restrictions apply, so that other third-party prod-ucts with equivalent functionality can be used as well. The only prerequisite is that the identity provider product supports SAML as standard protocol for the authentication.

In “On-Premise Products for IAM and GRC,” we explained how the SSO experience and user account provisioning and deprovisioning can be set up in on-premise landscapes.

However, what is interesting in the context of this guide is the setup in the cloud as well as the integration between on-premise and cloud components. Let us assume that the central user store is on premise. This turns out to be the case for most of our large customers. Needless to say, this scenario also works with a central user store in the cloud.

In a pure cloud environment, all applications use SAP Cloud Platform Identity Authentication for authentication. To integrate with identity authentication, cloud applications must configure their trust relationship with this service and enter the tenant of identity authentication as a trusted identity provider (see the right side of Figure7).

To integrate with identity authentication, cloud applications must configure their trust relationship with the SAP Cloud Platform Identity Authentication service and enter the tenant of identity authentication as a trusted identity provider.

SSO with SAP Cloud Platform Identity Authentication


40 / 52

Figure7:IdentityProxyforLoggingOntoCloudApplications

Corporateuser store

Corporateidentity provider

Identity provider proxy

SAP®

Trust configuration

Administrator:Set up trustrelationship

Administrator:Set up trustrelationship

Trust configuration

Reissue SAML

application

In a hybrid setup, a connection between identity authentication and an on-premise (corporate) identity provider must be estab-lished first. For this purpose, the SAP Cloud Platform Connectivity service must be installed and configured accordingly.33 Figure 7 does not show the cloud connector because, strictly speaking, this component does not participate

in the SSO flow. Once the connection has been established, authentication is performed by using identity authentication as the identity provider proxy. As you can see in Figure 7, identity authentication does not require its own user store. However, for this setup to work, the cloud applica-tion must register SAP Cloud Platform Identity Authentication as the trusted identity provider.

In a hybrid setup, a connection between identity authentication and an on-premise (corporate) identity provider must be established.

33. https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US /e54cc8fbbb571014beb5caaf6aa31280.html.




41 / 52

The flow is as follows: A user wants to access a cloud application by starting the respective URL (right side of Figure7). No session has been established yet. For this to happen, the cloud application requests authentication. This is done through a browser redirect. The cloud application acts as the service provider. SAP Cloud Platform Identity Authentication was configured to be the trusted identity provider, so this is the target for the browser redirect. Since it has been configured as the identity provider proxy, SAP Cloud Platform Identity Authentication forwards the browser redirect to the corporate user store.

For the corporate identity provider to authenticate the user, SAP Cloud Platform Identity Authentication now acts as the service provider and receives the SAML assertion that the corporate identity provider issued. The service then reissues this SAML assertion by applying the following changes: First, the service

enters the destination of the cloud application that started the authentication request. Second, it applies the trust configuration between identity authentication and the cloud application. This reissued SAML assertion is then provided to the cloud application. Once this is done, the user can be properly authenticated and the session to the cloud application established.

This scenario has clear advantages. Only one connection must be opened between the authenticating identity provider and the identity authentication service in the cloud. The corporate identity provider does not need to know anything about all the service providers in the cloud. This information is configured in SAP Cloud Platform Identity Authentication. The identity provider proxy scenario allows a setup in which no provisioning of user data to identity authentication is required. All user data is kept in the corporate user store.

For the corporate identity provider to authenticate the user, SAP Cloud Platform Identity Authentication now acts as the service provider and receives the SAML assertion that the corporate identity provider issued.


42 / 52

To achieve integration with additional cloud solutions from SAP, an identity provider proxy scenario including the third-party identity provider can be configured.

THIRD-PARTYCLOUDIDENTITYPROVIDERSCustomers may be using third-party products as identity providers. As stated earlier, to achieve integration with additional cloud solutions from SAP, an identity provider proxy scenario, including the third-party identity provider, can be configured. The prerequisite is that the identity provider in question supports SAML and can therefore be part of an identity provider proxy scenario.


43 / 52

In a landscape consisting of heterogeneous systems, one challenge is the fact that different systems use different user identifiers to log on. While some systems require the e-mail address for the logon, others identify users by a user name or an issued identifier. For example, alphanumeric IDs in an organization may start with different letters, depending on whether the user is an employee, a customer, or a partner.

SINGLESIGN-ONFOR SERVICE-TO-SERVICECALLSFor authentication by means of SAML, the heterogeneity of user IDs is no problem. The identity provider contains service provider– specific information and issues the SAML assertion with the appropriate subject name identifier and additional attributes needed for the targeted service provider. In addition to this configuration, trust has been established

between service providers and their trusted identity providers. This is performed in the application’s trust configuration.

In contrast, different user IDs may pose a challenge in case of service-to-service calls. In many scenarios, applications running in one system need information from another system. For example, in the SAP Analytics Cloud solution, the data that is being analyzed is retrieved through a live connection from the systems where the original data is located. System landscapes running SAP S/4HANA and the SAP Hybris Cloud for Customer solution are examples of targets for this live connection. While SAP Analytics Cloud can be configured to require the e-mail address for logon, (for example, “[email protected]” for user John Doe), SAP S/4HANA might require a user name such as “JDOE” for logon.

Different user IDs may pose a challenge in case of service-to-service calls. In many scenarios, applications running in one system need information from another system.

Special Case: Service-to-Service Calls


44 / 52

OAUTHSAMLBEARERFLOWFor service-to-service calls, the OAuth SAML bearer flow is the most commonly used approach. This flow requires no user interaction. The calling system is designated the OAuth client,34 whereas the target system is referred to as the OAuth resource server. To get access to the requested resource in the target system, the OAuth client must present a valid OAuth access token. The OAuth client requests this token from the OAuth authorization server. The latter can be either a component within the target system or a separate system. Prerequisite for receiving this access token is that the identities of both the OAuth client and the initiating user are verified. The OAuth client verifies its identity by providing the corresponding credentials when calling the authorization server. Within the OAuth SAML bearer flow, a SAML assertion provides the

identity of the user. Since acquiring this assertion does not require any user interaction in a flow, the user has a full single-sign-on experience.

By communicating the user’s identity to the OAuth resource server, all user-specific settings can be applied in the target system of the service-to-service call. Therefore, the services and data made available to the user can be restricted according to the user’s authorizations.

An SAML assertion for the OAuth SAML bearer flow is needed to prove the user’s identity. To obtain this assertion, two different setups are possible:1. A setup that uses a local identity provider

implementation2. A setup that calls a central security

token service

By communicating the user’s identity to the OAuth resource server, all user-specific settings can be applied in the target system of the service-to-service call.

34. For more information, consult https://tools.ietf.org/html/rfc6749.



45 / 52

Figure8:Service-to-ServiceCallwithOAuthSAMLBearerFlow

1b. Response with SAML assertion

Identity provider proxy

Reissue

®

SAML Assertion

SAML Assertion

SAML Assertion

SAML Assertion

SAML Assertion

2

Local identity provider

The option involving a local identity provider implementation is shown in Figure 8. First, to authenticate the user toward cloud application A, an SAML assertion is issued by the local identity provider and passed on to SAP Cloud Platform Identity Authentication (steps 1a and 1b), which acts as the identity provider proxy (see the section “SSO with SAP Cloud Platform Identity Authentication”). As soon as the user starts an application that requires data from cloud application B, the service-to-service call is started.

The local identity provider implementation uses the information from the SAML assertion as obtained for the authentication. It takes this information together with the trust between cloud application A and cloud application B and applies the destination information for cloud application B to reissue the SAML assertion. This reissued SAML assertion is then used for the OAuth SAML bearer flow (step 2).

The local identity provider implementation uses the information from the SAML assertion as obtained for the authentication.


46 / 52

Figure9:Service-to-ServiceCall:OAuthSAMLBearerFlow–SecurityTokenService

2b. Response with reissued SAML assertion


Reissue

1b. Response with SAML assertion

Identity providerproxy

Applicationtrust

configuration

Security tokenservice (STS)

SAML Assertion

SAML Assertion

SAML Assertion

SAML Assertion

2

SAML Assertion

SAML Assertion

SAML Assertion

As mentioned previously, a security token service can be alternatively used to issue the SAML assertion required for the OAuth SAML bearer flow. The flow of this second option is shown in Figure 9.

The authentication of the user toward cloud application A takes place as described in the first option (the local identity provider implementation using the information from the SAML assertion as obtained for the

authentication). However, in this second option, as soon as the service-to-service call occurs, the calling cloud application A calls the security token service to obtain the SAML assertion for the OAuth SAML bearer flow (steps 2a and 2b). As SAP Cloud Platform Identity Authentication does not store any information about the user, all necessary information must be made available for SAP Cloud Platform Identity Authentication. This is achieved by passing the SAML assertion from the initial authentication along with the call to the security token service.

As SAP Cloud Platform Identity Authentication does not store any information about the user, all necessary information must be made available for SAP Cloud Platform Identity Authentication.


47 / 52

It is important to mention that the target cloud application B might require more attributes in the SAML assertion than the calling cloud application A. On the other hand, the SAML assertion issued to cloud application A carries all user information from the corporate user store. That means that you need to configure the corporate user store accordingly. It should include all information that cloud application B requires in the SAML assertion, which was initially issued for the user’s authentication in cloud application A.

When reissuing the SAML assertion in SAP Cloud Platform Identity Authentication, the application trust configuration contains the service provider–specific information and thus knows which subject name identifier and which SAML attributes are needed for which service provider. By reading the user information available in the initial SAML assertion for cloud application A and applying the service provider–specific information about cloud application B, it is possible to issue the SAML assertion that the OAuth SAML bearer flow will use (step 3). For the process to complete successfully, however, each application must have defined its trust configuration with its respective identity provider in order to inform the system where to get user identity– relevant information, including destination information.

When reissuing the SAML assertion in SAP Cloud Platform Identity Authentication, the application trust configuration contains the service provider–specific information.


48 / 52

Figure10:OverviewoftheMainFunctionalityofaSIEMSystem

SIEM system

Forensicanalysis

Logcollector

Another service

Another service

Another cloud app

Log events

Log events (with retention)

Alertframework

SECURITYINFORMATIONANDEVENT MANAGEMENTFigure 10 shows a typical setup for a SIEM system. In a landscape with heterogeneous systems, enterprises are interested in detecting suspicious activities. They might be repeatedly failed logons, unusual modifications of user accounts or account permissions, attempts to

access confidential data, or attempts to perform unauthorized operations. To detect such incidents, adequate log events must be created in the respective systems. They are then transmitted to a central SIEM system. Figure 10 shows that various activities can be performed in that central SIEM system.

In a landscape with heterogeneous systems, enterprises are interested in detecting suspicious activities. They might be repeatedly failed logons, attempts to access confidential data, or attempts to perform unauthorized operations.


49 / 52

In the SIEM system, you can analyze log events by data aggregation, user, system, and other criteria, or even combinations of them. The system can perform analyses by correlation, for example, by looking for further events with similar characteristics, such as from the same IP address or geolocation. You may search for events through forensic analysis by looking at the data in a given time interval, in a specific selection of systems, and other criteria. If the analyses are automated, alerts can be created when issues based on predefined patterns are detected. Dashboards show system activities in informational charts. Compliance can be achieved by appropriately gathering and preparing data, for example, in reports.SAP has offerings with SIEM functionality, including the SAP Enterprise Threat Detection application,35 which is on-premise software. SAP Enterprise Threat Detection is the basis for operating our global cyberdefense and response center to monitor the internal system landscape

at SAP. In the future, SAP plans to offer further SIEM services for cloud scenarios.

We realize that our customers want to choose for themselves what SIEM system they use. It may be a third-party SIEM system or, in the future, an offering from SAP. Therefore, SAP plans to consider both scenarios. Our plan is to enable integrated cloud software that supports SIEM. A first step in the plan is to provide the respective APIs (highlighted in pale blue in Figure10) that will connect to the customers’ SIEM system. The latter should support log collection from all monitored systems (highlighted in orange in Figure10).

It is worth mentioning that as of today, no industry standard exists that can be used for the log transmission. That’s why it’s planned that all cloud software from SAP will offer an API to support transmission of security log events in the customers’ SIEM system (by push or pull).

In the SIEM system, you can analyze log events by data aggregation, user, system, and other criteria, or even combinations of them.

35. https://help.sap.com/viewer/p/SAP_ENTERPRISE_THREAT_DETECTION.


https://help.sap.com/viewer/p/SAP_ENTERPRISE_THREAT_DETECTION

50 / 52

OUTLOOKThe main purpose of this CIO guide is to show how IAM contributes to successful system integration. Moreover, the document discusses the approach SAP plans to take to enhance the user experience in a seamless system integration with the best possible system security, regardless of the type of environment (cloud or hybrid).

SAP is currently working on specific topics to enrich existing CIAM functionality. Among these, we mentioned three new solutions in the SAP Hybris portfolio acquired from Gigya offerings (see the section “B2C: Customer Identity and Access Management”). The SAP Hybris Identity, SAP Hybris Consent, and SAP Hybris Profile solutions support the strategy from SAP for consumer identity and access management.36

They also aid enterprises that need to collect customer data in compliance with the European Union’s GDPR while delivering personalized user experiences. The products can be deployed separately or as a package. While discussing the identity lifecycle, we mentioned data privacy and consent management. In this respect, it is of utmost importance for SAP and its customers to consider that the GDPR is in force starting May 25, 2018. Though this is a topic that does not directly relate to IAM and system integration, it is worth mentioning. We also would like to point out that data protection and privacy are corporate requirements at SAP. SAP is committed to imple-menting internal processes to comply with the GDPR. In addition, SAP offers many solutions that support end-to-end data protection opera-tions and facilitate compliance with the new legislation.

Data protection and privacy are corporate requirements at SAP. SAP is committed to implementing internal processes to comply with the GDPR and offers many solutions that facilitate compliance with the new legislation.

36. see www.hybris.com/en/downloads/product-collateral /gigya-sap-solutions-trusted-valued-relationships-customers/155.


http://www.hybris.com/en/downloads/product-collateral/gigya-sap-solutions-trusted-valued-relationships-customers/155


51 / 52

While this document contains information on identity and access management scenarios in which employees and consumers connect to cloud and hybrid landscapes, details for handling B2B scenarios are yet to be finalized. In these scenarios, customers enable users from different associated organizations (partners) to work in their system landscape. Currently, customers can invite partners to register and work with a given application. In the future, SAP plans to offer services for self-registration to enable associated organizations to request access to applications, including workflows and approvals. For this purpose, the single-sign-on functionality across different tenants will be enabled to avoid the necessity of creating new credentials for partners.

Another topic not elaborated on in this document is provisioning of authorization assignments to users. While SAP Cloud Platform Identity

Provisioning does support provisioning of user accounts, provisioning of authorization entities is still under construction. One central challenge is the enormous heterogeneity of these entities in different systems. Whereas in one solution roles are assigned to users, other solutions have groups or profiles. These entities can even be nested, for example, groups that include other groups and roles. For cloud and hybrid landscapes, SAP is currently working on a new approach to address this challenge.

There is still work to be done with respect to SIEM services in the cloud, and we are currently working on a concept to provide integrated cloud-based software support for SIEM. Since no industry standards are available for log transmissions, it is planned that SAP applications will provide APIs to facilitate this by pushing log events to – or pulling that information from – the customers’ SIEM log collector.

There is still work to be done with respect to SIEM services in the cloud, and we are currently working on a concept to provide integrated cloud-based software support for SIEM.


52 / 52

Find Out MorePRODUCT-RELATEDLINKSSAP Cloud Platform Identity Authentication service

• HelpPortal • SAPCommunity

SAP Cloud Platform Identity Provisioning service • HelpPortal • SAPCommunity

SAP Cloud Identity Access Governance software • HelpPortal • ProductOverview

SAP Cloud Platform Connectivity service • HelpPortal • How-ToGuide

“IdentityandAccessManagementinCloudandHybridSAPLandscapes” article in SAPinsider SAP Single Sign-On application

• On-premiseapplication • SSOCommunity

SAP Identity Management component • On-premisesolution • SAPCommunity

The SAPHybrisportfolio includes three new solutions from Gigya, now a part of SAP: SAP Hybris Identity, SAP Hybris Consent, and SAP Hybris Profile

• SAPHybrisIdentity • SAPHybrisConsent • SAPHybrisProfile

Altiscale

STANDARDSSAML

• SecurityAssertionMarkupLanguage(SAML)v2.0OASISStandard

• SecurityServices(SAML)Technical CommitteeWikiatOASIS

OpenID Connect • OpenIDConnect • OpenIDFoundation

SCIM • Definitions,Overview,Concepts, andRequirements(RFC7642)

• Coreschema(RFC7643) • Protocol(RFC7644)

OAuth 2.0 • OAuth2.0 • OAuth2.0authorization framework(RFC6749)

• SAML2.0profileforOAuth2.0client authenticationandauthorization grants(RFC7522)

• OAuthaccesstokenlifetime • OAuthclient • Security tokenserviceframework, definedbyOASIS

Other • Technicalarchitecturemodeling • SAPCommunity • GDPR • SAPCloudTrustCentersite • “CIO Guide: Process and Data Integration

in Hybrid Landscapes”



https://wiki.scn.sap.com/wiki/x/yy67Gg


https://wiki.scn.sap.com/wiki/x/Eoj5Gg


http://www.sap.com/products/cloud-iam.html


http://www.sap-press.com/cloud-connector-for-sap-cloud-platform-how-to-guide_4528

http://www.sap.com/documents/2017/04/9259bce2-b67c-0010-82c7-eda71af511fa.html

http://www.sap.com/documents/2017/04/9259bce2-b67c-0010-82c7-eda71af511fa.html




https://www.sap.com/community/topic/identity-management.html


http://www.hybris.com/de/downloads/product-collateral/sap-hybris-identify-engage-customers-channels-devices/152

http://www.hybris.com/de/downloads/product-collateral/sap-hybris-consent-build-customer-relationships-transparency-control/153

http://www.hybris.com/de/downloads/product-collateral/sap-hybris-profille-power-trusted-digital-experiences-first-party-data/154

https://news.sap.com/sap-welcomes-altiscale-provider-of-high-performance-big-data-as-a-service-solution

http://www.oasis-open.org/standards#samlv2.0

http://www.oasis-open.org/standards#samlv2.0

https://wiki.oasis-open.org/security/FrontPage

https://wiki.oasis-open.org/security/FrontPage

http://openid.net/connect






https://oauth.net/2






http://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime


http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust-1.4-spec-ed-01.html#_Toc162064951

http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust-1.4-spec-ed-01.html#_Toc162064951

http://www.fmc-modeling.org/home




© 2018 SAP SE or an SAP affi liate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affi liate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifi cations may vary.

These materials are provided by SAP SE or an SAP affi liate company for informational purposes only, without representation or warranty of any kind, and SAP or its affi liated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affi liate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affi liated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affi liated companies’ strategy and possible future developments, products, and/or platforms, directions, and functionality are all subject to change and may be changed by SAP SE or its affi liated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to diff er materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affi liate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies.

See www.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices.

57352enUS(18/05)

www.sap.com/contactsap

Follow us

https://twitter.com/sap

https://www.facebook.com/SAP

https://www.linkedin.com/company/sap

https://www.youtube.com/user/SAP

Documents

CIO Guide: Identity Lifecycle in Hybrid Landscapes - sap.com€¦ · 6 / 52 To explain how IAM software from SAP supports you in fulfilling the requirements related to system integration