early this year I checked out and watched the most interesting TechEd sessions in the SAP IAM space. This is a summary of relevant aspects without claiming to be complete.

This blog

contains updates from SAP TechEd concerning the SAP Cloud Identity Services
deals with user provisioning through SCIM APIs and the approach of using one aggregated user-provisioning endpoint for SAP cloud solutions
outlines some aspects of the integration between SAP SuccessFactors solutions and SAP Cloud Identity Services
provides an overview of the SCIM standard

But before we dive deeper into those topics, let’s start with some basics.

IAM challenges in the SAP space

There are several challenges related to authentication and identity management for SAP cloud applications:

Single sign-on (SSO) management: SAP cloud systems often require multiple login credentials for different applications and services, which can be difficult for users to manage.
Identity and access management (IAM): Ensuring that only authorized users have access to the appropriate resources can be a challenge, particularly in large organizations with many users and multiple SAP cloud systems.
User provisioning and de-provisioning: Managing the process of adding and removing users from SAP cloud systems can be time-consuming and error-prone, particularly when there are many users and multiple systems involved.
Password management: Ensuring that users have strong passwords and regularly update them can be a challenge, as can resetting passwords when necessary.
Integration with external systems: SAP cloud systems may need to be integrated with other systems or services, which can be a challenge if the systems use different authentication protocols or methods.

These days ensuring the security of authentication and identity management systems is critical to protect against cyber threats such as hacking and identity theft.

Benefits and Purpose of SAP Cloud Identity Services

Many companies have moved to cloud-based solutions to improve their efficiency and reduce their costs. As a result, they need to have strong security policies in place to protect their data and manage their user identities.

SAP Cloud Identity Services play a key role in these efforts by providing a centralized system of authentication and authorization that allows users to access critical resources without having to create multiple usernames and passwords. They also make it easier for businesses to manage user credentials and prevent unauthorized access to sensitive information. This is especially important as companies move more of their operations to the cloud. SAP Cloud Identity Services can be used by companies of all sizes to streamline workflows and secure sensitive documents while reducing their risk of data breaches and other attacks.

The benefits of SAP Cloud Identity Services include improved efficiency, enhanced security, and better management of user identities. Besides Single Sign-On the identity lifecycle management capabilities enable businesses to effectively manage the creation, use, and expiration of user accounts. Identity management is the process of maintaining information about users and their identities to ensure that these users can access their systems and provide the appropriate level of access to sensitive information.

The main purpose of SAP Cloud Identity Services is to provide one aggregated authentication and authorization endpoint for SAP Cloud applications. This ensures secure access to SAP Cloud services and helps organizations to manage the lifecycle of user identities and their permissions. Furthermore, even on-premises SAP systems can be integrated related to ID-Management and authentication.

Single Sign-On and MFA

By providing a seamless single sign-on (SSO) experience, SAP Cloud Identity Services help organizations to access corporate resources more easily and securely.

Many businesses have not enabled SSO for employees to gain access to enterprise applications in the SAP cloud. This can make it difficult for users to access their information quickly and efficiently. It also puts data at increased risk of security breaches. Therefore, organizations need to enable SSO and MFA to enhance the security of their data and improve the user experience.

Many customers are connecting SAP Cloud Identity Services as a proxy to their corporate IDP to reuse existing processes for authentication, SSO, and MFA. This way they decide if the user identifiers and claims are just forwarded as received from the corporate IDP or managed through the IAS utilizing its user persistence and group management interfaces.

This way, customers control the authorization independently allowing for the separation of Azure and SAP security administration teams. Lastly, there are interfaces to automate everything using APIs through an existing IAM solution.

Identity Lifecycle and integration with existing IDM solutions

IT administrators can use SCI to maintain a database of user information that is centrally stored and accessible throughout the organization. This information is used to provide users with access to different applications and cloud services based on their roles and responsibilities within the organization.

In general, by centralizing the administration of user accounts an IAM reduces the risk of unauthorized access and also helps minimize the costs of administering and maintaining user accounts across multiple systems and applications.

In conjunction with SAP Cloud Identity Services, SAP companies can use their existing identity management systems (on-premises or cloud). Despite an existing IDM solution, the SAP IPS is still required as part of the SCI in most cases. It acts as a central SCIM interface to many SAP cloud systems. Any SAP solution supported via an IPS connector can thus be operated via IPS as a SCIM proxy system, even if the remote SAP cloud systems themselves may not yet have a SCIM API.

The customers IAM solutions are only replicating to the SCI once and from there SCI is provisioning into the different applications.

In this context, the SCIM standard has become vital in the SAP cloud ecosystem due to its ability to communicate securely with a wide range of cloud-based applications.

This blog outlines the most important integration scenarios.

Note: The usage of SAP Cloud Identity is not mandatory for SAP customers, but it is a recommended solution for managing user identities and access to SAP applications and services. Customers can choose to use other identity management solutions, such as on-premises or other cloud-based IDM if they prefer. The choice of identity management solution will depend on the specific needs and requirements of the organization.

TechEd Updates

This section is about challenges related to IDM and SAP solutions. It deals with user provisioning through SCIM APIs and the approach of using one aggregated user-provisioning endpoint for SAP cloud solutions. Furthermore, it outlines some aspects of the integration between SAP SuccessFactors solutions and SAP Cloud Identity Services.

Identity Management and SAP solutions

Different identity and user-provisioning APIs

Most cloud solutions from SAP offer an application-specific API for user provisioning, many of them are still flat file uploads.
Different applications expose their internal perspective of user attributes, they are not harmonized which makes it difficult for customers to manage them.
Different behavior of user groups and roles makes it hard to manage those objects from a customer’s IDM tool.

Many SAP SaaS applications and services on SAP BTP require user replication

Customers must manage users in many small services

User provisioning through SCIM APIs

Already some years ago, SAP decided that all solutions will expose a SCIM API. The benefit for customers is to make use of standard SCIM connectors (no more custom development effort for IDM Connectors) and this way manage such applications using their existing IAM tools.

Status today (2023) the big 5 cloud solutions from SAP expose a SCIM API already, especially S/4HANA Cloud; SFSF, Ariba, Concur and Fieldglass. The remaining cloud applications are on SAP’s roadmap and will come up with changes or newer APIs. As of now, those APIs expose the most relevant (identity) attributes and some user attributes.

SAP is working on standardizing how to assign a user to user groups and roles throughout applications thus SCIM tools can manage user-role assignments more consistently between SAP solutions. Keep in mind that the authorization definitions are still managed in the application themselves, they cannot be managed by SCIM, but the user assignment is done via SCIM.

SAP is working on standardizing the user attribute names and semantics throughout the applications (plan till end of 2024). This improves application consistency as the same attributes will be named the same throughout the SAP application landscape. The SAP Global User ID addresses the challenge of integrating user-related data across system boundaries. It provides the means for establishing an enterprise-wide mapping of users. For integration scenarios with SAP Task Center, you need it as a common identifier. Here the Global User ID acts as a correlation attribute. Its value uniquely identifies a user across the landscape and helps the SAP Task Center relate tasks from different systems to that user.

Summary%20%231

Summary #1

One aggregated user-provisioning endpoint for cloud solutions from SAP

The SCI (IAS/IPS) provides one aggregated user-provisioning endpoint for cloud solutions from SAP. SAP is creating more Apps on the BTP (SAC, Fiori Launchpad, SAP Build Work Zone) and Services like Task Center using the Cloud Identity Services (SCI) for user management.

In addition, many customers are using S/4HANA Cloud; SAP SuccessFactors, and SAP Ariba. As of today, customers must replicate users into many different applications and services using their IAM processes.

SCI act as one centralized user-provisioning endpoint for cloud solutions from SAP providing default user schemas and transformations, and increased provisioning automation. Using integration, the customers’ IAM solutions are only replicating to the SCI once and from there SCI is provisioning into the different SAP applications.

Vision: SAP plans to automate the user provisioning and the target is to offload this task from the customers so they don’t need to take care of the transformations and monitoring of provisioning/user replication activities. Reconciliation will help to detect and provide means to cure or fix such inconsistent or broken user attributes throughout the SAP application landscape.

Summary%20%232

Summary #2

Best Practices

SAP Cloud Identity Services with its capabilities of secure authentication, identity federation, SSO, and SCIM-based identity provisioning are a core element in SAP BTP.

Establish central SAP Cloud Identity Services tenants to manage your identities
Integrate your leading source systems via SAP IPS to read and enrich identity information and persist all required user attributes (and group assignments) for all SAP cloud applications in the Identity Directory
Automate SCIM-based provisioning and management of your identities for all SAP cloud applications with SAP IPS
Integrate your existing IDM solution with the SCI to establish a workflow-driven hybrid IAM scenario
Integrate all SAP SaaS applications and SAP BTP accounts with your IAS tenants to centralize trust management across the many SAML service providers
Simplify SAML Name ID and claims management for all SAP applications
Delegate and centralize authentication for all SAP applications to your corporate identity provider and use identity federation
Use existing security features and policies, authentication processes including single sign-on and multi-factor authentication

Integration between SAP SAP SuccessFactors and SCI

SAP SuccessFactors (SFSF) integrates with SCI for smooth SSO and additional authentication capabilities and to sync identities (employee master data) to Identity Directory. This way SFSF works as a source system for the identities of workforce persons. Customers manage the lifecycle of employees in SFSF solutions and create, maintain, and terminate employees in SFSF which syncs the corresponding identity changes to the SCI (IdDS).

In the SFSF release (b2211) there are service integration improvements to the SCI integration:

With 2211 SFSF will deliver the SCIM API: Compared with OData API SCIM has many advantages and will be the default Integration approach of IDM in SFSF solutions. IPS will deliver a new SCIM connector for this and replaces the regular sync job.
Real-time sync to solve customer requirements: allowing employees to start their work w/o having to wait for regular job runs.
Tenant provisioning (integration by default): New customers will obtain preconfigured integration with SCI (IAS/IPS)
Improved integration with related SAP solutions: With the SCIM-based approach identities of a workforce person can be synced from SFSF to SAC and SAP Build Work Zone
Global User ID is planned to be used as the common user identifier in the integration between different SAP Apps: It aims to solve the problem of identifying a user across the system boundary. An immutable ID is a unique identifier that cannot be changed or modified. In general, immutable IDs are preferred in situations where it is important to maintain a consistent, unique identifier for a resource or entity
There are two approaches for implementing SAP Global User ID: The recommended approach is using the SAP Cloud Identity Services to generate and distribute Global User ID. In this case, the attribute is automatically generated by Identity Authentication at user creation. Its value is populated in the User UUID field for every newly created, imported, or provisioned user. After that, Identity Provisioning distributes it to various SAP applications. The alternative approach is to use or generate your own value for Global User ID and distribute it to SAP applications using existing IDM systems.

Some customers manage ID attributes like username, email, phone numbers, and the likes in the corporate IDM. Typically, the IAM solution reads entities from SFSF first and enriches them with additional attributes and provides a writeback to SFSF. The SCIM API provides the capability for customers to write these attributes to SAP SFSF solutions. Also, the Global User ID can be provided through the SCIM API generated from the customer’s IAM tool instead of the IAS.

Future enhancements in the SCIM API (expose roles, etc.) are planned for b2305 and beyond to further improve integration scenarios.

Note: Keep in mind in SAP S/4HANA there is another API to provision user attributes (the Employee Master Data API). SAP will keep on using it in the S/4HANA context and for the most relevant user attributes.

Summary of System for Cross-domain Identity Management (SCIM)

SAP has integrated SCIM into several of its products and services to enable organizations to manage user identities and automate common tasks, improving efficiency and reducing the risk of errors.

Since its introduction in 2014, the SCIM standard has been adopted by over 300 certified partner solutions from more than 50 technology vendors including Amazon AWS, Citrix, Dell EMC, HPE, IBM, Microsoft, Oracle, and SAP itself. This rapid growth is a testament to the power of the SCIM standard and the benefits that it delivers to the SAP ecosystem.

Introduction to SCIM

This section aims to provide an overview of SCIM and its purpose, including the problem it solves and its key features and benefits.

System for Cross-domain Identity Management is a standard protocol that enables organizations to manage and automate the process of creating, updating, and deleting user accounts across multiple systems and applications. It helps organizations to centralize and simplify the management of user identities, reducing the risk of errors and ensuring consistency across systems.

The problem that SCIM solves is the complexity of managing user identities across multiple systems and applications, especially in large organizations that have many different systems and applications in use. Without a standard protocol like SCIM, each system and application would have to be managed separately, which can be time-consuming and error-prone.

SCIM provides a common language and set of rules that different systems and applications can use to communicate and exchange user identity information, making it easier to manage user accounts and reduce the risk of errors.

One of the key ways in which SCIM enables seamless integration between different systems and applications is through the use of APIs (Application Programming Interfaces). An API is a set of protocols and tools that enable different systems and applications to communicate and exchange data with one another. SCIM provides a simple, REST-based API that enables developers to easily integrate it into their applications. This allows different systems and applications to use SCIM to exchange user identity information and automate common tasks such as user provisioning and de-provisioning.

SCIM is designed to be simple and easy to use, with a straightforward REST API that enables developers to quickly integrate it into their applications. It is also highly extensible, allowing organizations to customize it to meet their specific needs and requirements. It is based on an object model in which the resource object represents the base object and other objects such as users, groups, etc. are derived from it. A detailed description of the SCIM scheme can be found in RFC 7643. In RFC 7644 you can find the methods and endpoints defined in the SCIM specification.

SCIM is an HTTP-based protocol that works according to the client-server principle in which JSON payloads are exchanged. The SCIM client is the Identity Provider, such as the SAP Identity Management System, SAP Cloud Identity Provisioning Service (IPS), or the SAP IAG, which takes on the role of the Single Point of Truth for the identities in an organization. The information is then provisioned from the IDP to the service provider (SP), i. e. cloud-based applications such as SAP Analytics Cloud or Microsoft Azure, or queried from there.

SCIM standard and protocols

This section explains the SCIM standard and the various protocols it supports, such as HTTP, JSON, and OAuth.

The SCIM standard is defined in a series of specification documents published by the Internet Engineering Task Force (IETF). These documents outline the various components of the SCIM protocol, including its data model, API, and security requirements.

SCIM supports a number of different protocols and technologies and uses the HTTP protocol to transmit data and communicate with other systems and applications.

SCIM uses the HTTP POST, GET, PUT, and DELETE methods to enable clients to create, read, update, and delete user accounts, respectively. These methods are commonly known as the CRUD (Create, Read, Update, Delete) operations. Moreover, SCIM’s support for the HTTP PATCH method enables clients to efficiently make partial updates to user accounts, improving efficiency and reducing the risk of errors.

Create: The HTTP POST method is used to create new user accounts. When a client sends a POST request to the SCIM server, it includes a JSON-formatted representation of the new user in the request body. The SCIM server then creates a new user account based on the information provided in the request.
Read: The HTTP GET method is used to retrieve information about existing user accounts. When a client sends a GET request to the SCIM server, it specifies the user ID of the user it wants to retrieve in the request URL. The SCIM server then returns a JSON-formatted representation of the user in the response.
Update: The HTTP PUT method is used to update existing user accounts. When a client sends a PUT request to the SCIM server, it includes a JSON-formatted representation of the updated user in the request body. The SCIM server then updates the user account based on the information provided in the request.
Delete: The HTTP DELETE method is used to delete existing user accounts. When a client sends a DELETE request to the SCIM server, it specifies the user ID of the user it wants to delete in the request URL. The SCIM server then deletes the user account.
Patch: In addition, SCIM supports the HTTP PATCH method for updating existing user accounts. This method is used to apply partial updates to an existing resource, rather than replacing the entire resource as with the HTTP PUT method. This can be useful in cases where only a few attributes of a resource need to be updated, as it allows clients to send a smaller payload and avoid the need to retrieve the entire resource before making the update. SCIM uses the HTTP PATCH method in conjunction with the “patchOp” attribute, which specifies the operation to be performed (e.g., “add”, “replace”, “remove”) and the target attribute to be modified. The client sends a JSON-formatted representation of the patchOp in the request body, and the SCIM server applies the specified operation to the target attribute.
- The PATCH and PUT methods are both used to update resources in SCIM (System for Cross-domain Identity Management) systems, but they differ in how they handle updates to the resource. In summary, when updating resources in a SCIM system, you should use PUT if you need to update the entire resource representation, and you should use PATCH if you only need to update a partial resource. The choice between PUT and PATCH will depend on the specific needs of the update and if the version of the SCIM API supports it.
- PUT is used to update a complete resource, and it requires the entire resource representation to be sent in the request body. When using PUT, all attributes of the resource must be included in the request, even if they are not being updated. This means that if an attribute is missing from the request, its value will be overwritten with a null or default value.
- On the other hand, the PATCH method is used to update a partial resource, and it only requires the updated attributes to be sent in the request body. When using PATCH, only the attributes that are being updated need to be included in the request. This makes PATCH more flexible and efficient than PUT, as it allows for partial updates to be made without having to send the entire resource representation.

JSON: SCIM uses the JavaScript Object Notation (JSON) format to encode and transmit data. JSON is a widely used, human-readable data interchange format that is easy to parse and generate.

OAuth: SCIM supports the OAuth 2.0 protocol for authentication and authorization. OAuth allows users to grant third-party applications access to their resources without sharing their login credentials.

These protocols and technologies enable SCIM to operate as a flexible, interoperable system that can be easily integrated into a wide variety of systems and applications.

SCIM in action

Some examples of how SCIM is being used in real-world scenarios, such as user provisioning and de-provisioning in cloud-based applications, or automating user onboarding and offboarding processes.

User provisioning in cloud-based applications: SCIM can be used to automate the process of provisioning new user accounts in cloud-based applications, such as SaaS (Software as a Service) applications. When a new user is added to the organization’s directory, SCIM can automatically create a corresponding account in the cloud application, eliminating the need for manual account creation and ensuring that users have access to the applications they need as soon as they join the organization.

Automating user onboarding and offboarding processes: SCIM can be used to streamline the onboarding and offboarding processes for new and departing employees. When a new employee is hired, SCIM can be used to automatically create accounts in all the necessary systems and (SAP) cloud applications, ensuring that the employee has access to the tools they need as soon as they start. When an employee leaves the organization, SCIM can be used to automatically delete their accounts and revoke their access to company systems and data.

SCIM and security

SCIM can help organizations to improve security and reduce risk by simplifying and automating the process of managing user identities and ensuring that user account information is accurate and up-to-date across all systems and applications.

Here are a few ways in which SCIM helps to improve security and reduce risk:

Centralized user management: By centralizing user management, SCIM can help organizations to reduce the risk of errors and ensure that user account information is consistent and up-to-date across all systems and applications. This can help to prevent unauthorized access and reduce the risk of data breaches.

Automated provisioning and de-provisioning: SCIM can automate the process of creating and deleting user accounts, ensuring that users have access to the tools they need as soon as they join the organization and revoking their access as soon as they leave. This can help to prevent unauthorized access and reduce the risk of data breaches.

Compliance: SCIM can help organizations to meet compliance requirements by providing a standard protocol for managing user identities and ensuring that user account information is accurate and up-to-date. This can help organizations to demonstrate compliance with regulations such as the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA).

SCIM and the future

Like any technology, SCIM is constantly evolving to meet the changing needs of organizations and users. Let’s take a look ahead to the future of SCIM and how it may evolve to meet the changing needs of organizations and users.

One way in which SCIM evolves is through the release of new versions of the specification documents that define the standard. The Internet Engineering Task Force (IETF) is responsible for maintaining and updating the SCIM specification documents, and it releases new versions of the documents from time to time to reflect changes and improvements to the standard.

Another is through the development and adoption of new technologies and protocols. For example, SCIM 2.0, the latest version of the standard, introduces support for JSON Web Tokens (JWTs) as an alternative to OAuth 2.0 for authentication and authorization. This enables organizations to use JWTs to securely authenticate and authorize users when accessing SCIM resources.

The main differences between SCIM API v1 and v2 are:

Functionality: SCIM API v2 offers additional features not available in v1, including more complex queries and additional attributes for describing user objects.
Performance: SCIM API v2 is generally faster than v1 due to optimized architecture and better handling of large data sets.
Security: SCIM API v2 provides improved security features.
Interoperability: SCIM API v2 is designed to improve interoperability between different identity and access management systems.

In summary, SCIM API v2 is an improvement over v1 in terms of functionality, performance, security, and interoperability.

Overall, SCIM is a constantly evolving standard that is designed to meet the changing needs of organizations and users. SCIM will likely continue to evolve and adapt to new technologies and requirements in the future.

Tags: Identity Provisioning SAP Identity Management SAP Single Sign-On

Sara Sampaio

Author Since: March 10, 2022

0 0 votes

Article Rating

0 Comments

Inline Feedbacks

View all comments

TOC