Figure 1: 
Figure 2 IAM common architecture (SAP cross architecture, technology & innovation)
Integrated master-data- and identity-flows
What is it, what is the intention and what is in for you?
With SAP’s Integration Plan in the Cloud, distinct suite qualities were introduced. Those suite qualities are getting more important for the whole SAP portfolio. You as a customer get end-2-end automated solutions across different applications aligned with the business processes. Capabilities which belong to multiple applications are defined in those suite qualities centrally like the topic security and identity management.
You may also take look at the SAP Integration Strategy Community Topic Page to stay informed and please ask questions.
In this blog post series, we want to share the recommended architectures which offer you options to adapt the intelligent enterprise design for identity access management (IAM). Still this blog post will not be able to provide answers for all questions around how to setup IAM in a specific landscape. The intention is rather to provide food for thought for what to take into account.
We will concentrate on employee related integration scenarios (B2E).
There are corresponding blog posts dealing with reference architectures for single sign-on posted by my colleague marko.sommer.
In discussions about modern technical designs, apps often use protocols like OAuth2, OpenID Connect for service-to-service communication based on the assumption that authentication and authorization are the only main pillars of IAM. This is not wrong, but it misses the fact that the identities have lifecycles and often apps need data replication, sometimes even across data centers too. Aligned with the SAP Secure Operations Map we focus on:
- The identity life cycle
- The authentication flows
- The authorization and governance flows
The three pillars are different perspectives on the topic IAM. All of them have connections to each other and should be treated as a whole as shown in the next figure.
Consider the following example about how the three perspectives are connected: For an identity to authenticate, it must first exist and in the best case, its creation takes place automatically. During the authentication a check of the attributes should happen in regard to the defined authorizations. The authorizations should be defined upfront to have a clear segregation of duties – ideally risk free. This could also happen implicitly during the first successful login with the data from the token. In regard to data privacy and protection rules, the distribution of a deletion request must also be processed properly across the landscape. In case of data replication, protocols like OpenID Connect lack this possibility and we need an additional channel.
Each perspective has its own flow, but they all work together.
In this blog post we would like to share the identity life cycle and possible replications across the landscape.
The identity access management reference architectures for the Intelligent Enterprise are based on the SAP One Domain Model used in the SAP Master Data Integration service and the usage of the SAP Cloud Identity Services. The blog post is based on the principle that some of the applications can be exchanged – based on your requirements – but some applications are very important to allow an automation of the flows which might make them mandatory for your landscape. The intention is to reduce point-to-point connections in your landscape to allow the automation of flows e.g., the onboarding of a new SAP application.
The SAP portfolio for identity access management contains multiple offerings. You as our customers have invested in our and also 3rd party solutions. This blog post series explains the boundaries, the possible integration points and milestones for your journey to cloud with us.
What does the big picture look like and why?
Scenario 1 – the integrated master-data and identity flow
The SAP apps in this scope are:
- SAP SuccessFactors (Employee Central)
- SAP Master Data Integration (MDI) and SAP Master Data Orchestration
- SAP Cloud Identity Services
- SAP S/4HANA Cloud çjust as one example application simplifying the figure – you can replace it with your SAP SaaS/PaaS solutions
The current master data integration
Today the integration typically is done directly from SAP SuccessFactors to the SAP Cloud Identity Services and directly from SAP SuccessFactors to SAP S/4HANA Cloud as shown in the next figure.
The designated master data and identity flow
The official usage of SAP Master Data Integration and SAP Cloud Identity Services for SAP on-premises and SAP cloud applications was introduced some weeks ago.
The first data for an employee is entered in the human resources solution, here: SAP SuccessFactors. The set of attributes contain time-slices for the correct validity. This dataset is handed over to SAP Master Data Integration as the central distribution hub for master data. SAP Master Data Orchestration allows you to specify the attributes and rules how SAP Master Data Integration treats the data. SAP Master Data Integration uses the SAP One Domain Model.
Figure 3 IAM reference architecture: Master Data Integration & Cloud Identity (SAP cross architecture, technology & innovation)
SAP S/4HANA already contains the business user concept. This concept mainly uses business partner entities of type employee to link them with user entities to establish the business user. This linkage removes the redundancy of identity data which existed in e.g., SAP ECC. On the other hand, it requires the awareness and the maintenance of the business partners (type: employee), in the best case via automatic integrations from the HR-solution.
The SAP S/4HANA essential edition (SaaS/Cloud) acts in this design as master data client for the employee data stream from SAP Master Data Integration. SAP S/4HANA consumes the workforce person to maintain the business partner of type employee. This approach allows a central node for a landscape of multiple SAP client applications.
The SAP Cloud Identity Services work as master data client of SAP Master Data Integration to get all updates on the workforce person (SAP One Domain Model entity) to automatically create, modify, or end the corresponding identity.
The SAP Cloud Identity Services offer configuration options to determine access and to provision or just enable the correct user for the target applications like SAP S/4HANA. Not all business partners (employee) in an SAP S/4HANA require a user, but all users (employee) require a business partner. In the SAP S/4HANA system the entities of a user and the business partner will be linked together by the tools.
The described flow results in the following figure:
Figure 4 IAM reference architecture: Cloud Identity & Cloud Identity Access Governance (SAP cross architecture, technology & innovation)
The SAP Cloud Identity Services contain multiple services fulfilling specific purposes. The most well-known service is the SAP Cloud Identity Services – Identity Authentication service. The second well-known service is the SAP Cloud Identity Services – Identity Provisioning service. And the third, silently released service is the SAP Cloud Identity Services – Identity Directory service, which offers a store with a flexible schema and a more powerful API. The Identity Directory service is already automatically used by the Identity Authentication service and the old API is still supported.
Where to integrate with the E-Mail attribute?
Identity lifecycle attributes like the e-mail address are important because for some SaaS/PaaS solutions it is also used as identifier and even used as SubjectNameIdentifier in the authentication token. The e-mail can be maintained in the workforce-person record in SuccessFactors already, but not all employees might need an (business) e-mail address to do their job. In integrated scenarios like this the interaction with the (business) e-mail system should happen with the SAP Cloud Identity Services. The identity which is distributed across the landscape typically needs this attribute. There might be exceptions, but in general it is needed for notification flows. In the setup with the SAP Cloud Identity Services only, amend the e-mail to the identity via the SCIM API.
What to use as technical identifier?
In short: Use the user UUID of the SAP Cloud Identity Services. As stated, the e-mail is an important attribute and often used as a logon alias to make it easy for persons to authenticate to a system. Often the e-mail is used at the same time as an identifier. This has some advantages and disadvantages – which would fill its own blog post and I will not dig further into now. To sum-up: Within the SAP Cloud Identity Services a user UUID (universally unique identifier) is generated the moment you store the identity. This user UUID works as an identifier across the SAP landscape including hybrid scenarios. It is difficult for humans to read and remember it, so it is not a logon alias, but it is unique and good for the apps and micro services to use. For existing landscapes, you can do a silent adoption by provision it as additional but not leading identifier and using it in tokens as secondary identifier. For new apps, it offers you a clear path for the technical integration.
Please note – we heard your feedback. Some of you already defined such unique identifiers in your organization and you want to use them instead. The options and the outlook for those identifiers are not part of this particular blog post. It is good to only have one unique identifier, but this blog post focuses on the generated user UUID as reference.
Target systems
SAP S/4HANA is, in figure 3 an example for several SAP applications – the recommendation is to use the SAP Cloud Identity Services for SAP SaaS/PaaS apps like a new SAP BTP subaccount or SAP S/4HANA essential edition (formerly known as public cloud). The SAP Cloud Identity Services offer integrated scenarios and connectors – even if some of the SaaS applications have public APIs which could be used directly.
The creation or changes to an identity will be distributed across the landscape – mainly via the master data but changes also have an effect on the identity and the authorizations.
For the authorization management, SAP Cloud Identity Access Governance determines such changes and creates access requests for an approval flow to process the distributed changes (figure 4).
Figure 5 IAM reference architecture: Cloud Identity & Cloud Identity Access Governance incl. on-premises (SAP cross architecture, technology & innovation)
This approach can also be used for your on-premises SAP landscape by a "cloud driven" Identity Access Management as shown in figure 5. The benefit would be a lean landscape without redundant tools on-premises. If you want to safeguard your investments into on-premises Identity Access Management tools then stay tuned. These complex scenarios will be covered in other blog posts.
Pros
- Seamless central master data distribution
- Central identity flow
- Easy integration for Governance Risk and Compliance flows with SAP Cloud Identity Access Governance
- Additional SAP applications can be easily amended
Cons:
- In case of only one SAP application, it contains the little overhead with the SAP MDI and SAP Cloud Identity Services
Recommendation:
- Use this setup as a designated long-term target or if you are new to SAP
Conclusion
The identity access management for the Intelligent Enterprise contains services which aim for a higher automation and easier integration of SAP into your landscape – no matter whether SaaS/PaaS/on-premises. The guiding principles and the greenfield architecture define a target. For existing landscapes, we want to guide you from brownfield scenarios to our reference architectures. In particular for the identity lifecycle, we want to bundle the different sources to have a clear workforce person flow as input for the identity flow. Identities contain only subsets of the workforce person attributes. Identities amend additional identifiers and authorizations. Those identities are being aligned across the landscape. In regard to the SAP applications, the SAP Cloud Identity Services either work as an interface for existing (SaaS/PaaS) apps with their own user managements or as a single-point-of-truth management solution for new (SaaS/PaaS) apps, which do not contain their own user management. To ensure an identity lifecycle end-2-end, it is recommended to store identities centrally in our SAP Cloud Identity Services. Those services replicate and manage the connections beyond. This is especially the case for SAP apps which have their own user management. This also allows a deletion trigger at the end of a life cycle. New lightweight apps can rely on the central services and only use tokens from the SAP Cloud Identity Services instead of a user replication. The aim of the reference architectures is to have one single approach for you as a customer instead of various point-to-point connections with specialties in each of them.
What we will share next
We are planning to release multiple reference architectures based on this structure.
Please also read the corresponding blog posts:
- Single Sign-On: SAP Reference Architecture for Identity Access Management
- Identity Lifecycle: SAP Reference Architecture for Identity Access Management – Part 2
- Identity Lifecycle – SAP HCM or 3rd-party-HCM as employee source (planned)
References
CIO Guide: Identity Lifecycle in Hybrid Landscapes
Secure Operations Map
SAP Cloud Identity Services community
Evolving IAS and IPS into SAP Cloud Identity Services
Task-Center
- SAP Managed Tags:
