SAP Identity and Access Management – Integration Approaches

On-premises and Cloud applications in the same landscape is the norm today with seamless integration between SAP and non-SAP applications. Add multi-user store, SSO with MFA, access management and compliance to this and it becomes challenging to develop such a hybrid model. The question is, how do organizations achieve secure access governance in such a complex landscape?

This article provides an answer to these governing processes which are the key challenges of a secure environment.

Key Challenges:

It focuses on three critical pillars of security ‘User Lifecycle’, ‘Secure authentication’ and ‘Access Management’, which are addressed here considering a hybrid environment.

It cites commonly used applications and their integration and the important functionalities.

A Hybrid scenario showing integration calls with SAP and non-SAP applications

 

User lifecycle:

Consider a scenario where multiple user sources such as SuccessFactors (SF), SAP HCM, Microsoft Azure, Microsoft Active Directory (AD), SAP ABAP system, SailPoint, ServiceNow, SAP IAS and SAP IDM contribute parts of User data between them.

How do we handle this complex integration? Should identity governance be centralized or is a federated model more flexible in a multi-cloud, hybrid environment?

A common scenario being Azure or AD as the source of user id for Contractors while SF & HCM for Employees. These can then merge at GRC, IAS or IDM which then becomes the hub of User records.

To give a more realistic picture of the above scenario, SuccessFactors and HCM can automate the Joiner-Mover-Leaver processes with GRC/IAG through HR triggers. GRC can read user details from AD and Azure through standard and cloud-connector. While IDM or IAS have standard connections with SF and HCM. Any existing ABAP system can also serve as the user source and the same can be cascaded to connected systems.

More recently, ServiceNow is being used to submit forms for onboarding of contractors. This form-data can then be saved to a file system server for being read by applications such as SAP IDM. GRC access control can also receive access requests from SNOW through REST API calls.

The other challenge around multiple sources of User-data is that of authentication.

Authentication:

There are multiple ways in which Cloud applications can be exposed and authenticated.

Should organizations prioritize federated identity over direct authentication?

This article highlights the common scenarios of accessing cloud apps, using few example scenarios.

a. BTP Services such as IAG: Access to IAG can be granted to end users and they can be authenticated at Identity Provider (IDP). This IDP can be IAS, Corporate Network or any SAML 2 compliant application. IAS also serves as a proxy identity provider with authentication being routed to Microsoft ADFS or Azure AD. These sources of authentication generate SAML2 based logon tickets for authentication to ABAP systems.

b. SAP S/4 Cloud: Direct authentication between the cloud applications with Azure AD can also be set-up. Please refer https://learn.microsoft.com/en-us/entra/identity/saas-apps/sap-fiori-tutorial

c. On-Premise Applications are best suited for authentication at the Corporate User store.

SAP IAS is recommended by SAP as a proxy-hub for authentication. It also facilitates in MFA.

Access management:

Provisioning can take place through a central IDAM (Identity and Access Management) tool or through a combination of such tools. Some examples are below.

For cloud applications, IPS and IDM can provision roles and groups with risk analysis and approval processes managed through IDM or IAG.

GRC can co-exist with IAG for On-Premise applications, a model called IAG Bridge. GRC or IAG can initiate a risk analysis call by themselves or can IDM or SailPoint can invoke the same.

SailPoint has been in use recently to act as a user hub and is integrated with GRC primarily for Risk analysis. This takes place through a standard connector in SailPoint for GRC through which it can receive User and Role data for all connectors from GRC. Furthermore, access requests can then be raised in SailPoint with approval workflows and calls sent over to GRC for Risk analysis.

Business users using FIORI apps (eg. of S/4 cloud) can access the same at BTP. IPS helps in provisioning users of S4 at BTP. This approach of allowing users to use FIORI apps is called the Central FIORI launchpad.

Conclusion:

The question is no longer whether to integrate but how to do so it securely and efficiently.

The answer lies in centralizing identity where possible by integrating governance tools such as GRC, IAG and SailPoint and leveraging proxy identity providers like SAP IAS.

This article is designed to help Security and non-technical consultants understand the basic architecture of security in a Hybrid environment. Looking forward for your valuable feedback.

 

Author Details

PLABAN SAHOO

Plaban has 19 years of experience as a Sap Security, SAP GRC Access and Process Control, SAP IDM and SAP BTP security.

Leave a Comment

Your email address will not be published. Required fields are marked *