SAP Community - SAP Cloud Identity Services

2024 SAP Cloud Identity Services & IAM Portfolio: What’s New?

2024-02-28T19:10:38.504000+01:00

This blog explores the latest 2024 updates in SAP's Identity and Access Management (IAM) portfolio derived from various early 2024 SAP events, particularly focusing on SAP Cloud Identity Services (SCI).

IAM 101: Identity Lifecycle, Authorization, and Authentication

In simple terms, Identity and Access Management (IAM) revolves around three core aspects:

Identity Lifecycle: This encompasses the journey of user identities within a system, from creation to deletion.
Authorization: Determining what actions users are allowed to perform within a system.
Authentication: Ensuring that users are who they claim to be when accessing applications or services.

Identity Access Management Portfolio by SAP

SAP offers a Identity Access Management (IAM) portfolio that caters to both on-premises and public cloud solutions. Let's delve into each category - Identity Lifecycle, Authentication, and Authorization - highlighting the different components within SAP's Cloud Identity Services (SCI) suite.

Source SAP SE: Image from the SAP presentation showcased at the DSAG Technology Days 2024 in Hamburg

Identity Lifecycle Management

For managing the lifecycle of identities, SAP provides several solutions:

Identity Provisioning: Part of SCI. Facilitates seamless creation and management of user identities.
Identity Directory: Part of SCI. Serves as a centralized repository for user and group information.
SAP Identity Management: An on-premises product ensuring robust identity lifecycle management unitl the end of 2027/2030.

Authentication Solutions

SAP's authentication solutions ensure secure access to applications and services:

Identity Authentication: Part of SCI. Provides seamless and secure authentication for users across applications.
SAP Single Sign-On 3.0: An on-premises product offering single sign-on capabilities until the end of 2027.
Secure Login Service: A standout addition to SAP's IAM lineup is the SAP Secure Login Service, heralded as the new star in the SAP Single Sign-On horizon. This service promises enhanced security and user experience in single sign-on scenarios.

Want to know more? Read here: https://community.sap.com/t5/technology-blogs-by-members/exploring-sap-secure-login-service-for-sap-gui-a-comprehensive-review/ba-p/13573382

Authorization Management

Authorization management is crucial for defining user permissions and access control:

SAP Cloud Identity Access Governance: Symbiotically linked with SCI, it offers comprehensive authorization management and access governance.
Authorization Management of SAP Cloud Identity Services: Streamlines authorization management for developers on SAP BTP. Define access policies with specified conditions, easily adjustable by administrators post-deployment. This centralizes access control, mitigating complexity and ensuring precise authorization levels.

Want to know more? Read here: https://community.sap.com/t5/technology-blogs-by-sap/sap-btp-innobytes-january-2024/ba-p/13584601

SAP Access Control: An on-premises product offering that enables organizations to control access and prevent fraud across the enterprise, while minimizing the time and cost of compliance. An upcoming version (release 2026) will further enhance authorization capabilities within SAP's IAM portfolio.

While SAP's IAM portfolio boasts a comprehensive suite of solutions, it's worth noting that the SAP Customer Data Cloud is beyond the scope of this discussion due to the author's limited experience with it.

SAP Cloud Identity Services

Short Overview

SAP Cloud Identity Services (SCI) offer a suite of components tailored to address various facets of IAM:

Identity Provisioning: Streamlining the process of creating and managing user identities.
Identity Directory: Serving as a centralized repository for storing and accessing user and group information.
Authorization Management: Facilitating the assignment and management of user permissions.
Identity Authentication: Ensuring secure and seamless user authentication across applications.

Key Features of SCI

Predefined Connectivity and Bundling: SCI seamlessly integrates with SAP cloud solutions, providing out-of-the-box configuration for user provisioning and authentication.
Automated Service Enablement: Identity Services are automatically enabled as part of the product delivery process, simplifying setup for customers.
Default Pre-Configuration: SAP cloud solutions come pre-configured with Identity Services, catering to common scenarios without the need for separate licensing.

Source SAP SE: Image from the SAP presentation showcased at the DSAG Technology Days 2024 in Hamburg

Long story? Read here: https://xiting.com/en/downloads/download-sap-cloud-identity-services-e-book/

Cross-Enterprise Access Governance

Cross-enterprise identity management and access governance integration is set to be streamlined with the integration of Microsoft Entra ID and Microsoft Entra ID Governance alongside SAP Cloud Identity services and SAP Cloud Identity Access Governance. This integration will empower organizations to achieve single sign-on and provisioning capabilities across a range of SAP business applications, including SAP S/4HANA Public Cloud, SAP Ariba, SAP Concur, and SAP SuccessFactors. Furthermore, the linkage between Microsoft Entra ID and Microsoft Entra ID Governance with SAP Cloud Identity Access Governance will enable cohesive identity and access risk assessments, alongside monitoring and management of compliance controls.

Source SAP SE: Image from the SAP presentation showcased at the DSAG Technology Days 2024 in Hamburg

Identity Lifecycle Management with SCI

SAP Cloud Identity Services facilitates efficient management of the employee lifecycle, from onboarding to offboarding, ensuring smooth transitions and access management throughout.

It plays a key role by centralizing Identity Access Management. They collect the derived identities and act as a single source of truth. The Identity Directory and Identity Provisioning components of SAP Cloud Identity Services work together to manage identities efficiently across systems.

Identity Directory: Centralized User Management

The Identity Directory serves as a central repository for user and group information, accessible via APIs and admin UI, simplifying connectivity and integration with SAP SaaS applications. It provides a System for Cross-domain Identity Management (SCIM) 2.0 REST API for managing resources (users, groups and custom schemas) with a set of attributes. Those attributes are defined in the SCIM 2.0 Core schema and the Enterprise user resource schema. Custom attributes are supported through a schema extension.

Identity Provisioning

Transformation Engine

Identity Provisioning Connectors play a crucial role in the Identity Lifecycle process. These connectors come in various types, including Source System Connectors, Target System Connectors, and Proxy System Connectors. They enable seamless integration between different systems, allowing for the provisioning and authentication of users.

The Identity Provisioning transformation engine offers several powerful capabilities:

Assignment: Users can define rules for assignments based on input data. For instance, organizations can use the value of an identity's organizational unit to determine the roles required for that user.
Mapping between identity models: The engine facilitates mapping between attributes in different models. For example, it can map the surname attribute to the family name attribute. Additionally, it allows for adjustments to data formats, such as converting time or number formats as needed.
Filtering: Organizations can specify detailed criteria for determining which objects should be read or written. This enables fine-grained control over data synchronization and provisioning processes, ensuring that only relevant information is transferred between systems.

Various types of connectors to facilitate seamless integration

Source System Connectors: These connectors enable the extraction of user data from source systems, such as SAP Cloud solutions, on-premise solutions, and third-party solutions.
Target System Connectors: These connectors facilitate the transfer of user data to target systems, including SAP Cloud solutions, on-premise solutions, and third-party solutions.
Proxy System Connectors: These connectors act as intermediaries between source and target systems, ensuring smooth data transfer and integration.

With support for over 20 SAP Cloud solutions, on-premise solutions, and third-party solutions, Identity Provisioning Connectors offer out-of-the-box configuration for user provisioning and authentication. This ensures quick and easy setup for organizations, enabling efficient management of user identities across diverse systems.

Authorization Management

Authorization plays a crucial role in ensuring secure access to applications and resources. Here's how SAP addresses authorization management:

Internal Authorization Definition: Many applications define authorizations internally, tailored to their specific domain requirements.
Central User Assignment: SAP Cloud Identity Services centralizes user assignment to roles and groups, streamlining access management.
Authorization Management Service (AMS): This "new" service provides centralized management of end-user authorizations for applications on the SAP Business Technology Platform. AMS integrates seamlessly with SAP Cloud Identity Services, allowing for configuration and assignment of policies directly from the administration console.
Policy Assignment: In SAP Cloud Identity, each policy corresponds to a group in the identity directory. Policies can be assigned to users by making them members of the respective policy group. Customers have the flexibility to assign SAP-provided or custom policies to users using the user-friendly UIs in the SAP Cloud Identity console or programmatically via the SCIM API of the Identity Directory.

Source SAP SE: Image from the SAP presentation showcased at the DSAG Technology Days 2024 in Hamburg

Identity Access Governance

SAP Cloud Identity Access Governance (IAG) is already widely recognized, offering a comprehensive suite of features aimed at enhancing security and compliance.

Key Features:

Privileged Access Management: Enables the management of super-user access, log consolidation, and automated log assessment to ensure stringent security measures.
Access Certification: Facilitates the review of access, roles, risks, and mitigation controls to maintain compliance with regulatory standards.
Access Analysis: Provides tools to analyze access, refine user assignments, and manage controls effectively.
Access Request: Optimizes access by streamlining workflows, policy-based assignment, and processes to ensure efficient access provisioning.
Role Design: Allows organizations to optimize role definition and governance processes, enhancing overall security posture.

Moreover, SAP Cloud Identity Access Governance offers HR-driven identity lifecycle management by integrating with SAP SuccessFactors. This integration enables automatic access requests triggered by changes in employee status within the HR system. The IAG Bridge Cloud facilitates the creation of access requests for cloud applications, with risk analysis and provisioning handled by SAP Cloud Identity Access Governance.

API-based integrations further enhance flexibility, allowing external applications to submit requests to SAP Cloud Identity Access Governance for processing. This enables efficient access provisioning and deprovisioning based on approval processes, with the option to retrieve request status periodically.

With support for over 16 SAP Cloud solutions, on-premises solutions, and third-party solutions, SAP Cloud Identity Access Governance provides a robust platform for organizations to maintain security, compliance, and efficient access management across their IT environment.

Authentication

Authentication within SAP's ecosystem is facilitated through SAP Cloud Identity Services, serving as the interface for Identity Access Management. Here's how authentication in the overall hybrid SAP landscape idealy works:

SAP Cloud Identity Services: This platform acts as the primary hub for authentication. SAP applications inherently trust SAP Cloud Identity Services for identity authentication, ensuring a secure login process.
User Interaction: Users have the flexibility to interact with either Identity Authentication provided by SAP Cloud Identity Services or third-party Identity Providers. Regardless of the chosen method, users benefit from Single Sign-On capabilities, enhancing user experience and simplifying access to multiple applications.
Integration with SAP GUI: SAP GUI seamlessly integrates with short-term X.509 certificates from SAP Secure Login Service, further enhancing authentication security supporting MFA within SAP environments.

Source SAP SE: Image from the SAP presentation showcased at the DSAG Technology Days 2024 in Hamburg

Short Comparative Note: SAP Secure Login Service (SLS) for SAP GUI versus SAP Single Sign-On (SSO) 3.0. While SAP Single Sign-On 3.0 remains a viable solution for certain use cases, the emerging preference leans towards the new SLS for SAP GUI for most scenarios. The rationale behind this shift lies in the fact that SSO relies on capabilities like multi-factor authentication and CLM (Certificate Lifecycyle Management with NDES CA-Integration) on SAP NetWeaver Application Server Java, which is scheduled to exit mainstream maintenance by the end of 2027.

Source SAP SE: Image from SAP

Contrarily, the new SLS does not depend on SAP NetWeaver AS Java; instead, it leverages a cloud-based service. It emphasizes seamless integration with cloud-centric identity providers, such as SAP Cloud Identity Services – Identity Authentication. Furthermore, it is offered as a cloud subscription, aligning with the contemporary preferences of software licensing among customers. However, it is important to note that currently, some features are still missing in direct comparison with the SAP SSO 3.0 Suite.

Principal Propagation: SAP Cloud Identity Services facilitates principal propagation between applications, ensuring consistent authentication across various systems and enhancing interoperability.

Upcoming Developments and Enhancements

Upcoming: Simplified Principal Propagation for Authentication

SCI will act as a central token service, reducing complexity in system-to-system calls and enhancing trust between applications. In an upcoming development, SAP Cloud Identity Services is poised to introduce a significant enhancement aimed at simplifying principal propagation for authentication. Here's what to expect:

Central Token Service: SAP Cloud Identity Services will transition into a central token service, streamlining the process of system-to-system calls. This move aims to reduce complexity and enhance efficiency in authentication workflows.
Token Request Flow: When a sender application needs to call an API of the receiver application on behalf of the current user, it will request a token from Identity Authentication within SAP Cloud Identity Services.
Trust in Tokens: SAP applications, along with third-party applications, will trust tokens issued by SAP Cloud Identity Services for API calls. This trust ensures secure and seamless communication between applications, regardless of their origin.

Source SAP SE: Image from the SAP presentation showcased at the DSAG Technology Days 2024 in Hamburg

SCIM & SAP: Updates for Improved Enterprise Readiness

SAP is working on enhancements to the SCIM protocol, including cursor-based pagination and additional schema support, to enhance user assignment processes and enterprise readiness.

Here's an overview of the recent developments:

SCIM Adoption: SAP initially adopted SCIM as a product standard with the Identity Provisioning Service (IPS). SCIM2 was subsequently designated as the primary user and group replication protocol for SAP applications, outlining the implementation guidelines.
SCIM User Lifecycle: SCIM includes the "active" flag to control authentication and app interactions. It mandates responding to GET requests after a DELETE request with no result. Applications have the autonomy to set users to a blocked status or create new user records as needed.
Enterprise Readiness: SAP identified areas for improving SCIM's enterprise readiness, including the lack of delta-read processes and index-based pagination. To address these concerns, SAP is working on implementing cursor-based pagination for entities like Users and Groups, as well as multi-valued attributes.
SCIM Groups and Schema Enhancements: SAP envisions SCIM Groups as the primary method for user assignments, offering transparent concepts for SCIM clients. SAP's group schemas introduce additional capabilities, such as defining group types and supported operations, providing more precise operations for SCIM clients.
SAP User Extensions: SAP plans to introduce additional user extensions for business attributes derived from the One Domain Model (ODM). This extension aims to enable applications to create users with related business attributes. The schema will support legacy approaches and integration scenarios with the Master Data Integration Service.

Source SAP SE: Image from the SAP presentation showcased at the DSAG Technology Days 2024 in Hamburg

SAP Cloud Identity Services continue to evolve, offering comprehensive IAM solutions for businesses. With features such as predefined connectivity, automated service enablement, and upcoming enhancements, SAP remains innovative, ensuring secure and efficient identity and access management for its customers.

What’s New for SAP Build Apps – Mobile Authentication

2024-03-08T11:08:53.887000+01:00

Greetings Builders! This week we have released a significant feature for our customers: mobile authentication.

We have now enabled SAP Mobile Services, which authenticates end users in your native mobile applications and provides access to integrations and services from SAP Business Technology Platform.

SAP Build Apps uses SAP Cloud Identity Services – Identity Authentication (IAS) for user authentication in the cloud. For more information on this topic, see the article: What is Identity Authentication?

Now with the ability to harness the power of Identity Authentication, you can increase the enterprise readiness of your company’s mobile apps by ensuring seamless integration with SAP Business Technology Platform. This feature allows you to reuse destinations of backend systems, which are also used for web applications and many other BTP services.

To get started with taking advantage of this feature, verify that you have Subaccount entitlements of at least 1 unit for Mobile Services (standard plan) as a prerequisite.

After configuring mobile authentication in your BTP Cockpit and your build settings, you can build your first mobile app with authentication services enabled. Your users will be prompted to sign in with your Identity Provider (IdP) the first time they open your app. The session will remain active until the app’s cache is cleared or the session is revoked manually.

👉For instructions on getting started with mobile authentication, see the documentation: SAP Build Apps – SAP Mobile Services.

We look forward to seeing our customers unlock more possibilities by enabling mobile authentication in their apps! Feel free to share any feedback or questions about this release in the comments.

Check out what else is on the horizon for SAP Build Apps this year in the Roadmap Explorer.

To see all recent SAP Build Apps releases, visit the What’s New Documentation.

SAP IdM migration guidelines to help you on your upcoming IAM journey

2024-03-25T14:21:37.058000+01:00

Let me introduce to you the ROIABLE SAP IdM Migration Guidelines. Your one-stop information guide on important features, concepts and technicalities around an SAP IdM migration. With 94 topics covered, the guide encapsulates 15 years’ experience of SAP IdM implementations, operations, and enterprise support.

The content is future product agnostic, meaning you should be able to apply the explained concepts to any selected IAM of choice. Surely some will have advantages over others in certain areas, but using the above comprehensive guide, you will, at least, be able to ask all the right questions, when it comes to selecting the successor of SAP IdM.

Each topic is structured similarly, color-coded based on the category which it fits. The top left part is reserved for its number, name, and abbreviation. On the left, you can find a summary of its usage within the scope of SAP IdM, while on the right is a recommendation of how this particular topic should be migrated or not onto your future IAM platform. At the bottom you can find related topics to continue browsing the document or respectively return to the overview slide using the home button.

The various topics covered spread over 10 categories, which only shows the wide diversity to be considered when taking care of your SAP IdM migration. The document is still work in progress, but there are already released topics, which you can find here.

Stay tuned for the full release and its respective announcement. Till then, make sure to check the link above regularly for newly uploaded content.

Retain investment, stay compliant and embrace the cloud!

Safeguarding Data Privacy in KSA - Leveraging SAP to navigate NDMO’s Regulations in Digital Era

2024-03-28T12:05:30.971000+01:00

Blog v1.0 | Published On: 28 March 2024

Authors: @asadkhan02 , @AyeshaSafeer , @Zainab_ASalam

_________________________________________

In today's digital era, data privacy is a crucial issue for both individuals and organizations. The Saudi National Data Management Office (NDMO), in partnership with the Saudi Data and Artificial Intelligence Authority (SDAIA), has introduced stringent Data Governance and Personal Data Protection Standards. These regulations mandate all organizations operating across various industries in the Kingdom of Saudi Arabia comply by September 2024.

Failure to comply with these regulations can result in hefty financial fines reaching SAR 3 million or higher in some cases, reputational damage, legal consequences, and loss of trust among customers and partners.

To ensure compliance with these new regulations, organizations are encouraged to implement processes aligned with the 15 domains outlined by the NDMO for Data Governance and Personal Data Protection Standards. Leveraging technology as an enabler, organizations can implement robust data privacy measures and effectively meet these requirements.

Top 5 Areas part of 15 Domains outlined by NDMO for Data Governance and Personal Data Protection Standards

SAP, a global leader in enterprise software, provides advanced technologies with artificial intelligence (AI) capabilities that provide a solid foundation for organizations to implement data governance and personal data protection processes. SAP solutions enable Saudi organizations to efficiently navigate and fulfill regulatory requirements:

By implementing SAP solutions, Saudi organizations can empower their data privacy practices, mitigate compliance risks, and build trust among stakeholders. SAP technologies uphold data integrity, safeguard personal information, offer the framework for regulatory compliance implementation, and adapt to the demands of the digital age.

As a team at SAP, we are committed to supporting organizations in achieving their regulatory compliance initiatives. We invite you to take the next step by exploring how our technologies and solutions can assist you on this journey.

Contact us today to learn more about how SAP can help you navigate the complex landscape of data privacy regulations in Saudi Arabia and ensure compliance.

Integrating IBM Security Verify with SAP Cloud Identity Services in SAP BTP

2024-04-02T10:29:43.856000+02:00

This blog delves into the technical aspects of integrating IBM Security Verify with SAP Cloud Identity Services (CIS) in SAP Business Technology Platform (BTP) as a proxy.

SAP CIS offers a suite of solutions for managing user identities, access controls, and application integrations across the IT landscape. Conversely, IBM Security Verify provides identity governance, workforce and Customer Identity Access Management (CIAM), and privileged account controls through automated, cloud-based, and on-premises capabilities. By integrating these platforms, organisations can leverage their combined strengths to establish a secure business environment. This integration enhances operational control, regulatory compliance, and user experience in the digital era.

IBM Security Verify supports various authentication methods, including passwordless, fingerprints, and one-time passcodes, ensuring flexibility and robustness against unauthorised access. Meanwhile, SAP Cloud Identity Services serves as a comprehensive Identity and Access Management solution which is available in SAP BTP.

The integration process involves configuration updates in SAP CIS and IBM Security Verify to enable authentication utilising standard protocols supported by both components, such as SAML 2.0. Organisations must ensure they have the necessary admin privileges or access rights for editing configurations before initiating the integration procedure. Collaboration between the organisation and SAP is required for the integration, with most of the effort undertaken by the organisation.

Reference Architecture

The diagram represents a SAP Cloud Identity Service that integrates with IBM Security Verify though which various SAP BTP application(s), SAP SaaS solution(s) and on-premises application(s) can be accessed. It demonstrates user sign-in via IBM Security Verify which allow possible passwordless, bio-metric or multi-factor authentication (MFA) using mobile devices for fast application access and pleasing user-experience.

Prerequisites

SAP Cloud Identity Services(for trial instance check this link)
IBM Security Verify (for trial instance check this link)
A smartphone with IBM Security Verify App

Configurations and Settings in IBM Security Verify

When a user logs in, home screen as shown below will be displayed.

Now on the left panel, click on "Applications" under "Applications". On the right side of the screen, there is an “Add application” button. Click on it.

Fill the necessary details under “General” section as below and save the details.

Before we go further, let’s log into SAP BTP account and you will be navigated on SAP BTP Cockpit. As suggested below, navigate to the “Instances and Subscriptions” tab, which is under “Services”.

Upload the metadata file which you have recently saved on your device to IBM Verify dashboard

Configurations and Settings in SAP Cloud Identity Services

Now, get back to SAP BTP and navigate to “Instances and Subscriptions.”

Now, enable the “Cloud Identity Services” if it’s not and once done it will be accessible as below:

Once you click on “Cloud Identity Services”, you will be redirected to the login screen of the SAP authentication screen as shown below

After successful login, you can see the home screen of Cloud identity service. Go to the “Identity Providers” as highlighted below

Click on the Corporate Identity providers and create new identity provider

Once the new identity provider is added successfully, click on the identity provider type and select SAML 2.0 compliant as shown below

Go to the SAML configuration section and fill in the information as shown below.

You can browse the “Metadata” file from your device once you download it from IBM Security Verify dashboard. Go to “Sign on” section of the application and on the right side of the screen, download the file from the given URL and upload the same in SAP Cloud Identity Service as highlighted below:

Click on the Trusting application section and add SAP BTP trial sub-account.

Now, navigate back to SAP BTP cockpit and establish the trust configuration which is under “Security” section for the cloud identity application as shown in the below screenshots.

Select “Establish Trust”

You will see the below steps once you click on establish trust. As a first step, choose tenant and click on next.

After selecting a tenant in the next step choose the domain for your SAP Cloud identity services application.

Click on the next button and configure parameters as shown in below screenshot.

Click on the next button and make a final review of the setup you have done while establishing the trust. Then click on the finish button and save the details.

Once done, you can see the new active trust configuration as shown below.

To provide access to the user, click on the Users section which is inside the “Security” section on the left menu.

Click on the user and assign role collection to the user as shown below.

You can select different roles and assign them to the user. Here we have added three roles to the user. After selecting all the roles, click on the “Assign role collection” button and save the details.

We have completed the configurations in IBM Security Verify and SAP Cloud Identity Services. Let’s test it now by opening the SAP business studio application as shown below.

How does it work? Let’s Check.

Log into SAP BTP Cockpit and Navigate to “Instances and Subscriptions” under “Services” as highlighted below:

It will redirect to the sign in options screen of the SAP. Here, select SAP cloud identity service as an identity provider.

Once you select, it will redirect to the verify sign in option screen for a authentication. Here you can select a different sign in option for Verify or can log in with IBM id/Cloud directory.

Enter your IBMid for log in and click the continue button.

It will redirect you for w3 authentication screen where you can enter your w3 id & password.

Once you click on sign in, you will see below screen of SAP business application studio.

Click on the “OK” button and you will be redirected to the SAP Business Application Studio home screen.

Conclusion

To summarise, combining IBM Security Verify with SAP Cloud Identity Services via SAML 2.0 provides a strong solution for organisations wishing to:

Enhance security: By implementing multi-factor authentication and centralised user management, businesses may greatly minimise the risk of unauthorised access to vital data and applications.

Improve the user experience: SAML 2.0 integration offers single sign-on, which allows users to access various applications with a single login, eliminating login fatigue and increasing overall user experience.

Simplify identity management: Consolidating identity management across several platforms allows organisations to streamline administration operations and reduce the complexity of managing user access.

Overall, this integration enables organisations to achieve a balance between strong security and a user-friendly interface, building trust and confidence in this digital era.

Handling Third Party Cookies Deprecation in Identity Authentication

2024-04-08T10:55:44.430000+02:00

Background

A while ago Google announced the deprecation of third-party cookies for the Chrome-based browsers (Prepare for third-party cookie restrictions ). Starting Q1 2024, 1% of all browsers already have their third party cookies usage deprecated with the goal to completely phase out the old way of using cookies by mid-Q3 2024.

The Affected

As a result, certain sign-in scenarios concerning Single Sign-On (SSO) may be affected. Deprecating the traditional way of cookie usage means that browsers will automatically block cookies from applications embedded in inline frame (iframe), for example, thus braking sign-in flows. As Identity Authentication is often embedded on top-level pages, it had to ensure the SSO flow will continue to function. There are a couple of solutions that the administrators can implement after the start of the deprecation period.

The Solutions

Cookies Having Independent Partitioned State (CHIPS)

In this scenario, embedded applications can set partitioned cookies that can be used only on the current top-level site. The implementation of CHIPS depends on the developers of the given applications. The application has to be extended to support it. You can read more about that in Cookies Having Independent Partitioned State (CHIPS).

Storage Access API

This is also what Identity Authentication currently uses and supports. Read more at Storage Access API.

In the typical sign-in flow, the embedded application requests storage access permissions to the browser. Upon sign-in attempt, the user sees the following message: Once Continue is chosen, a request is triggered, asking the browser to present the possibility to allow access to cookies. The prompt is similar to the one below:
If access is allowed, the sign-in flow continues.

If denied, the sign-in flow of the embedded Identity Authentication sign-in screen is broken and no signing in is possible. The user sees the following message:

In another scenario, Identity Authentication can be used in a pure proxy mode. In this situation the browser of the user might have never interacted with the SAP (ondemand.com) domain. As a result, the browser blocks the iframed domain until the user interacts with it separately on a top-level.

To resolve this, Identity Authentication redirects the users to a separate page, where they have to perform some kind of interaction, so that the top-level domain of the page is considered "familiar" to the browser. This interaction is as simple as the confirmation to the message below:

In some situations this might cause confusion, since with the proxy mode configuration the users might not even know they are signing in via Identity Authentication, or that SAP is involved in the sign-in flow at all. However, there was no other option to work around the limitation than sending the user to a separate confirmation page. Once the interaction is done, the users no longer need to perform this step.

Deprecation Trial

Google Offering

For customers that would require more time to implement changes on their application, Google offers a grace period. During this grace period, an opt-out of the new way of handling cookies is possible. Customers can obtain their deprecation trial tokens from Google upon request. You can read more at Preserving critical user experiences.

Identity Authentication Solution

Identity Authentication supports such scenarios allowing customers to add their deprecation trial tokens so that they are sent via an HTTP header. This ensures that Identity Authentication customers with custom domains can use the deprecation trial for those domains respectively. The field to input the token is situated on the same place in the Identity Authentication admin console, where the custom domains are configured:

We will update this article if new updates or scenarios that we have not covered appear.

Configuration: SAP Ariba SSO with SAP Cloud Identity Services - Identity Authentication

2024-04-10T15:18:20.686000+02:00

See as well:

Table of Contents:

SAP IAS SAML Metadata Retrieval
SAP Ariba SAML Metadata Retrieval (PLICM-871)
SAP IAS SAML Authentication Configuration
SAP Ariba SAML Authentication Self-service Configuration (PLICM-871)
SAP Ariba SSO Verification
- Validate the SAP Ariba SSO via Intelligent Configuration Management
- Validate the SAP Ariba SSO by accessing the SAP Ariba URL in the browser
  - SAP Ariba without SSO
  - SAP Ariba with SSO to SAP IAS
  - SAP Ariba with SSO to Microsoft Entra ID

SAP IAS SAML Metadata Retrieval

To retrieve SAML Metadata from SAP IAS:

enter the below SAP IAS URL into browser:
https://<SAP IAS tenant id>.accounts.ondemand.com/saml2/metadata?action=download
store the downloaded SAP IAS Metadata File

SAP Ariba SAML Authentication Self-service Configuration (PLICM-871)

From 2402 release of "PLICM-871: Ability to Configure SAML Authentication Settings in Intelligent Configuration Manager" feature, customers can retrieve the SAP Ariba metadata file as self-service.

Note: In case of configuring the SSO setup for SAP Ariba Sourcing, SAP Ariba Contracts, SAP Ariba Supplier Lifecycle and Performance for suite-integrated tenants the SSO setup and thus the metadata retrieval needs to be executed on the SAP Ariba procurement tenant (e.g. for US DC https://<SAP Ariba tenant id>.procurement.ariba.com). In case of SAP Ariba multi-ERP configuration setup (f.k.a Federated Process Control FPC) the SSO configuration and metadata retrieval needs to happen for the parent tenant.
For standalone (not suite-integrated) SAP Ariba sourcing tenant (e.g. for US DC https://<SAP Ariba tenant id>.sourcing.ariba.com)

Prerequisites:

SAP Ariba user with Third Party Enterprise User (Ariba) type
SAP Ariba user with Customer Administrator group membership

To configure SAP Ariba SAML Authentication with SAP IAS:

enter the SAP Ariba tenant as per Note above using the Third Party Enterprise User (Ariba) login URL (e.g. for US DC https://<SAP Ariba tenant id>.procurement.ariba.com/?passwordadapter=ThirdPartyUser)
navigate to Manage -> (Core Administration - for SAP Ariba procurement tenant or Administration for SAP ariba sourcing tenant) -> Intelligent Configuration Manager -> Manage Configurations -> [Continue] -> Authentication -> [Update]
load the SAP IAS Metadata File you retrieved from SAP IAS
select Enable SAML authentication to Yes, to enable the SSO (all the data are pregonfigured from the imported SAP IAS Metadata File)
press [Submit]

press [Approve]

press [Apply] - after this step SAP Ariba SSO changes will take effect!

In case the Enable SAML authentication is set to Yes, SAP Ariba will use to authenticate the users credentials (passwords) stored in SAP IAS and not credentials (passwords) stored in SAP Ariba. Therefore SAP Ariba business users will need to be invited to SAP IAS, activate their accounts and create their user credentials (passwords)

In case the Enable SAML authentication is set to No, SAP Ariba will use to authenticate the users credentials (passwords) stored in SAP Ariba

Note: Users of type Third Party Enterprise User (Ariba), using the *?passwordadapter=ThirdPartyUser URL to login into SAP Ariba will always keep using credentials (passwords) stored in SAP Ariba, no matter of the SSO enablement

SAP Ariba SAML Metadata Retrieval (PLICM-871)

Prerequisites:

SAP Ariba user with Customer Administrator group membership

To retrieve SAML Metadata from SAP Ariba:

enter the SAP Ariba tenant as per Note above
navigate to Manage -> (Core Administration - for SAP Ariba procurement tenant or Administration for SAP ariba sourcing tenant) -> Intelligent Configuration Manager -> Manage Configurations -> [Continue] -> Authentication
download and store the appropriate Test or Production SAP Ariba Metadata File

Note: Because of current temporary gap in the SAP Ariba Metadata File generation, manual adjustment to the entityID attribute value is required as per the process described below.
(assumption here is that the SAP Ariba SSO SAML configuration was already setup and SAP Ariba tenant has SSO enabled)

Manual SAP Ariba Metadata File adjustment process:

Run chrome://extensions/ in Google Chrome browser
Navigate to Chrome Web Store

Search for SAML Chrome Panel -> [Add to Chrome]

Hit [F12] to open the Chrome DevTools
Open your SAP Ariba tenant URL in Google Chrome
(e.g. https://<SAP Ariba tenant id>.procurement.ariba.com)
Navigate to the Chrome DevTools -> SAML -> copy the value of the SAP Ariba SAML Request saml2:Issuer XML element (e.g. http://<SAP Ariba tenant id>.procurement.ariba.com)

Open the SAP Ariba Metadata File and replace the value of entityID attribute with the value of saml2:Issuer XML element, retrieved from SAP Ariba SAML in the Chrome DevTools and save the modified SAP Ariba Metadata File

SAP IAS SAML Authentication Configuration

Prerequisites:

SAP IAS user added as Administrator to SAP IAS (Users & Authorizations -> Administrators -> [Add])

To configure SAP IAS SAML Authentication with SAP Ariba:

enter the SAP IAS Administration Console via https://<SAP IAS tenant id>.accounts.ondemand.com/admin
navigate to Application & Resources -> Application -> [Create] to create Application for SAP Ariba as Service Provider (SP)
- Enter the Display Name, choose SAP Ariba solution as Type, SAML 2.0 as Protocol Type and hit [Create]

navigate to SAML 2.0 Configuration and upload the adjusted SAP Ariba Metadata File

SAML 2.0 configuration is pre-set out of the uploaded SAP Ariba Metadata File

hit [Save]

navigate to Subject Name Identifier and set the Primary Attribute Value to Login Name and hit [Save]

ensure the users setup in SAP IAS have the Login Name set and matching to the SAP Ariba user UniqueName
- navigate to Users & Authorizations -> User Management -> and specific user SAP IAS Login Name needs to match user SAP Ariba UniqueName

SAP IAS User Profile:

SAP Ariba User Profile:

In case you are reading this line, you have successfully configured the Single Sign-On (SSO) between SAP Ariba as Service Provider (SP) and SAP IAS as Identity Provider (IdP)!

SAP Ariba SSO Verification

To verify the status of the SAP Ariba SSO Setup follow one of the options below:

Validate the SAP Ariba SSO via Intelligent Configuration Management
Validate the SAP Ariba SSO by accessing the SAP Ariba URL in the browser

Validate the SAP Ariba SSO via Intelligent Configuration Management

Prerequisites:

SAP Ariba user with Customer Administrator group membership

To review existing SAP Ariba SSO setup:

enter the SAP Ariba tenant
navigate to Manage -> (Core Administration - for SAP Ariba procurement tenant or Administration for SAP ariba sourcing tenant) -> Intelligent Configuration Manager -> Manage Configurations -> [Continue] -> Authentication
check the SAP Ariba SSO configuration for Test or Production

Validate the SAP Ariba SSO by accessing the SAP Ariba URL in the browser

Validate the SAP Ariba SSO setup by accessing the SAP Ariba URL via browser - accessing the business user access URL (e.g. for US DC https://<SAP Ariba tenant id>.sourcing.ariba.com).

Below tests will not work in case browser certificate is used and the business user is logged in to SAP Ariba without entering credentials.

SAP Ariba without SSO

Reaching below SAP Ariba Login screen means, SAP Ariba SSO is not setup and SAP Ariba site requires the user credentials to be entered as stored in SAP Ariba

SAP Ariba with SSO to SAP IAS

Reaching below SAP IAS Login screen means, SAP Ariba SSO is setup with SAP IAS (directly, without further identity federation) and SAP Ariba site requires the user credentials to be entered as stored in SAP IAS

SAP Ariba with SSO to Microsoft Entra ID

Reaching below Microsoft Entra ID Login screen means, SAP Ariba SSO is setup with Microsoft Entra ID and SAP Ariba site requires the user credentials to be entered as stored in SAP Microsoft Entra ID

Note: You can achieve the usage of Microsoft Entra ID for SAP Ariba SSO via direct configuration to Microsoft Entra ID or via Identity Federation setup of SAP IAS, in case of Identity Federation, SAP Ariba SSO is setup to SAP IAS and SAP IAS delegates all the authentication requests to Microsoft Entra ID. Because of this we might not be able to recognize whether the SAP Ariba SSO is setup directly with Microsoft Entra ID or via SAP IAS Identity Federation.

See as well:

Overview: SAP Ariba SSO with SAP Cloud Identity Services - Identity Authentication

2024-04-10T15:19:19.410000+02:00

See as well:

Table of Contents:

Single Sign-On (SSO), Service Provider (SP), Identity Provider (IdP) and Identity Provider Proxy (IdP Proxy)
SAP Cloud Identity Services - Identity Authentication (SAP IAS - SAP Identity Authentication Service) Authentication Scenarios
- Identity Provider (IdP) - Authentication Scenario
- Identity Federation with Identity Provider Proxy (IdP Proxy) - Authentication Scenario
- Service Provider (SP) vs Identity Provider (IdP) Initiated Authentication
SAP IAS Landscape Review and Recommendations
- Review of Available SAP IAS Systems in Customer Landscape
- Review of SAP IAS System Customer Administrators
- Process of New SAP IAS System Provisioning

Single Sign-On (SSO), Service Provider (SP), Identity Provider (IdP) and Identity Provider Proxy (IdP Proxy)

Single Sign-On (SSO) is an authentication and authorization process that allows an User to access multiple enterprise applications with a single set of login credentials (username and password). Service Provider (SP) hosts a service (e.g. SAP Ariba Buying) that User wants to access. This Service Provider (SP) trusts the Identity Provider (IdP) (e.g. SAP IAS or Microsoft Entra ID), which controls the User access. SSO supports various protocols like Security Assertion Markup Language (SAML) or OpenID Connect.

Identity Provider (IdP)

System responsible for User authentication
Uniquely Identifies the User
Contains User Store with and additional User Attributes (name, mail, group membership, ...)
Contains User Credentials (username/password)
Issues additional User Attributes (name, mail, group membership, ...)
Trusts one or multiple Service Providers (SPs)

Service Provider (SP)

System delegating User authentication to Identity Provider (IdP)
Relies on the User identity and User Attributes from Identity Provider (IdP)
Trusts single Identity Provider (IdP)

SAP Cloud Identity Services - Identity Authentication (SAP IAS - SAP Identity Authentication Service) Authentication Scenarios

SAP Cloud Identity Services is SAP product for authentication and Single Sign-On (SSO) in cloud referred as SAP IAS (Identity Authentication Service) as well.

To be compliant with the latest SAP Ariba "Next Generation" solutions (e.g. SAP Ariba Category Management, Supplier Profile Summary in SAP Ariba Supplier Lifecycle and Performance, ...) it is mandatory to have the SAP Ariba solutions' Single Sign-On (SSO) setup with SAP IAS (Test or Production).

SAP IAS can be setup as Identity Provider (IdP) or configured with Identity Federation to serve as Identity Provider Proxy (IdP Proxy) to another Identity Provider (IdP) -> Customer Managed IdP (e.g. Microsoft Entra ID IdP).

Identity Provider (IdP) - Authentication Scenario

This authentication scenario assumes the User Store and User Credentials persistence in Identity Provider (IdP) - SAP IAS. Thus the user information needs to be available, activated, with generated credentials in Identity Provider (IdP) - SAP IAS.

To establish the SSO:

Metadata needs to be obtained from Service Provider (SP) - SAP Ariba
Application representing the Service Provider (SP) - SAP Ariba needs to be created in Identity Provider (IdP) - SAP IAS using the metadata retrieved from Service Provider (SP) - SAP Ariba
Metadata needs to be obtained from Identity Provider (IdP) - SAP IAS
SSO needs to be configured in Service Provider (SP) - SAP Ariba using the metadata retrieved from Identity Provider (IdP) - SAP IAS

SSO execution (IdP initiated):

User accesses Service Provider (SP) - SAP Ariba URL
Service Provider (SP) - SAP Ariba will forward the authentication to Identity Provider (IdP) - SAP IAS
Identity Provider (IdP) - SAP IAS login window asking for User credentials is shown
User is authenticated by Identity Provider (IdP) - SAP IAS, based on the entered credentials and the response with User Identifier and User Attributes is send to Service Provider (SP) - SAP Ariba

For configuration details see:

Configuration: SAP Ariba SSO with SAP Cloud Identity Services - Identity Authentication

Identity Federation with Identity Provider Proxy (IdP Proxy) - Authentication Scenario

Identity Provider Proxy (IdP Proxy)

System responsible for User authentication, with conditional Identity Federation to Identity Provider (IdP)
Uniquely Identifies the User or delegates it to Identity Provider (IdP)
Can contain User Store and additional User Attributes or delegates it to Identity Provider (IdP)
Can contain User Credentials or delegates it to Identity Provider (IdP)
Issues additional User Attributes (name, mail, group membership, ...) or delegates it to Identity Provider (IdP)
Trusts one or multiple Service Providers (SPs)
Can trust one or more Identity Providers (IdPs)

Note: SAP IAS shall be configured as Identity Provider (IdP) also in case of Identity Federation authentication scenario, as Identity Federation as Identity Provider Proxy (IdP Proxy) is extension configuration of Identity Provider (IdP) itself.

This authentication scenario assumes the User Credentials persistence is outside SAP IAS in Customer Managed IdP (e.g. Microsoft Entra ID IdP). User Store (containing User Attributes) can be in SAP IAS or outside SAP IAS in Customer Managed IdP (e.g. Microsoft Entra ID IdP). No User Credentials needs to be maintained in SAP IAS as the authentication is forwarded outside SAP IAS in Customer Managed IdP (e.g. Microsoft Entra ID IdP).

Note: In case User Store is required in SAP IAS (e.g. for SAP Ariba SAP Task Center or SAP IAS Group membership access restriction), the users needs to be imported into SAP IAS. One possible way is using automated solution via Identity Provisioning (SAP IPS - SAP Identity Provisioning Service).

To establish the SSO with Identity Provider Proxy (IdP Proxy) :

Steps from above Identity Provider (IdP) - Authentication Scenario chapter needs to be in place to setup the SSO between Service Provider (SP) - SAP Ariba and Identity Provider Proxy (IdP Proxy) - SAP IAS
Metadata needs to be obtained from Identity Provider Proxy (IdP Proxy) - SAP IAS
Identity Provider Proxy (IdP Proxy) - SAP IAS needs to be created as Service Provider (SP) in Customer Managed IdP using the metadata retrieved from Identity Provider Proxy (IdP Proxy) - SAP IAS
Metadata needs to be obtained from Customer Managed IdP
Corporate Identity Provider representing the Customer Managed IdP needs to be created in Identity Provider Proxy (IdP Proxy) - SAP IAS using the metadata retrieved from Customer Managed IdP

SSO execution with Identity Provider Proxy (IdP Proxy) (IdP initiated):

User accesses SAP Ariba Service Provider (SP) - SAP Ariba URL
Service Provider (SP) - SAP Ariba will forward the authentication to Identity Provider Proxy (IdP) - SAP IAS
Identity Provider Proxy (IdP Proxy) - SAP IAS (based on optional condition) forwards the authentication request to Identity Provider (IdP) - Customer Managed IdP
Identity Provider (IdP) - Customer Managed IdP (e.g. Microsoft Entra ID IdP) login window asking for User credentials is shown
User is authenticated by Identity Provider (IdP) - Customer Managed IdP, based on the entered credentials and the response with User Identifier and User Attributes is send to Identity Provider Proxy (IdP Proxy) - SAP IAS
User authentication with User Identifier and User Attributes is further send from Identity Provider Proxy (IdP Proxy) - SAP IAS to Service Provider (SP) - SAP Ariba

For configuration details see:

Identity Federation: SAP Ariba SSO with SAP Cloud Identity Services - Identity Authentication

Service Provider (SP) vs Identity Provider (IdP) Initiated Authentication

User can access the resource represented by Service Provider (SP) via one of below approaches

Service Provider (SP) initiated authentication

Service Provider (SP) and Identity Provider (IdP) needs to have the signing certificates (part of the metadata) exchanged
User accesses the Service Provider (SP) URL
(e.g. https://<SAP Ariba tenant id>.procurement.ariba.com)
Service Provider (SP) forwards the authentication to Identity Provider (IdP)
Identity Provider (IdP) authenticates the User and redirects to Service Provider (SP)

Identity Provider (IdP) initiated authentication

Service Provider (SP) needs to have signing certificate of Identity Provider (IdP) (part of the metadata) configured
Signing certificate of Service Provider (SP) is not required to be configured in Identity Provider (IdP) in case of IdP initiated authentication
IdP Initiated Authentication needs to be enabled in Identity Provider (IdP)
User accesses the Identity Provider (IdP) URL with Service Provider (SP) identifier passed
(e.g. https://< SAP IAS tenant id>.accounts.ondemand.com/saml2/idp/sso?sp=<service provider name>)
Identity Provider (IdP) authenticates the User and redirects to Service Provider (SP)

SAP IAS Landscape Review and Recommendations

Review of Available SAP IAS Systems in Customer Landscape

Customer can review his SAP IAS landscape via S-User in SAP for Me (https://me.sap.com) -> Systems & Provisioning -> Systems -> Public Cloud Systems

Above means that SAP Ariba Test tenant SSO shall be established with SAP IAS Test and SAP Ariba Production tenant SSO shall be established with SAP IAS Production!

Review of SAP IAS System Customer Administrators

Customer can review his SAP IAS landscape via S-User in SAP for Me (https://me.sap.com) -> Systems & Provisioning -> Systems -> Public Cloud Systems -> navigate to specific system link

Process of New SAP IAS System Provisioning

Follow SAP IAS Tenants documentation to:

review SAP IAS tenant types
review SAP IAS licensing and usage
review SAP IAS data centers availability

Follow SAP IAS Initial Setup documentation to:

review existing customer SAP IAS landscape
request Test SAP IAS tenant creation
request additional SAP IAS tenant creation

See as well:

Summary: SAP Ariba SSO with SAP Cloud Identity Services - Identity Authentication

2024-04-10T15:25:47.836000+02:00

Root article grouping the individual topics related to SAP Ariba Single Sign-On (SSO) and SAP Cloud Identity Services - Identity Authentication (SAP IAS)

Single Sign On to SAP Cloud Integration (CPI runtime) from an external Identity Provider

2024-04-11T06:53:39.270000+02:00

Introduction:

Yes, you read it right (and you read it right here !). There is an out-of-the-box approach to achieving a single sign-on (SSO) experience for user flows between a corporate identity provider (that authenticates and authorizes the user) and a tenant of Cloud Integration runtime (loosely called CPI worker) fully within the BTP ecosystem.

Ok, let’s zoom out a bit and break this down.

If you are reading this blog post, you probably know already that SAP BTP Services can leverage the OpenID Connect federation-based mechanics of SAP Cloud Identity Service (read: SAP IAS) to connect users from corporate Identity Providers like Entra ID (formerly known as Azure AD), Okta, etc. to XSUAA BTP’s OAuth Authorization Server.
This is certainly not uncharted and I did a detailed blog post a few months ago demonstrating this setup.

However, this setup applied mostly to browser-based SaaS applications (read: Design Time applications with a web frontend), and that brings us to the objective of this blog -> Customers want to put together a similar setup for their client applications that interface with SAP Cloud Integration’s IFLows (in other words, the CPI runtime).
Certainly, this is not impossible to achieve and solution blueprints like these have existed in the past:

My colleague Francisco’s blog puts API Management in between a client and Cloud Integration and enforces API Management to perform an OAuthSAMLBearer handshake.
Microsoft champion Martin Raepple teaches how to set up SAML Trust between Entra ID Identity Provider and BTP to set up a user impersonation flow.

However, these approaches were often seen as cumbersome to set up / troubleshoot and certainly not for the faint-hearted!

Solution Summary:

An easier solution can be described in two phrases: 'OpenID Connect' and 'Authorization Code grant type'. If you are super-smart then you've figured it out already. You can stop reading this blog and hack this yourself.
I wish you a nice day ahead! If you are like me and need a bit more explanation, keep reading 🙂

Here is the solution blueprint that explains that handshake:

SCENARIO: Flows that require end-user authentication from external Identity Providers can natively do so with OIDC and Authorization Code grant type

Step 0: Generate Service Instance / Service Key SAP Cloud Integration Runtime. Refer to this link. Instead of Client Credentials make sure to select Authorization Code.

Step 1: Onboard the needed corporate identity providers in SAP IAS and set up the 'Application' that connects back to your SAP BTP Subaccount as a Trusted Identity Provider via OpenID Connect. Refer to my previous blog post for a detailed procedure.

Step 2: Client (end-user) initiates a connection to the required IFlow (or API artifact). This kicks off the 3-legged OAuth user login flow.

Step 3: As the user is not signed in, she is redirected to XSUAA's login endpoint, and upon login the IAS tenant's OAuth server authorization endpoint at https://<IAS tenant name>.accounts.ondemand.com/oauth2/authorize is invoked using the authorization code grant type. The details of the actual federation as part of the handshake have been omitted here for simplicity. But suffice it to say that the authorization code from the identity provider is made available to the IAS's callback endpoint and finally made available to XSUAA's authorize endpoint and exchanged for the actual access token. This access token will bear the user's scopes and role permissions needed to access the Cloud Integration's IFlow resource.

Step 4: Once successfully authorized, on the receiver side of the IFlow, we will establish connections to 3 different types of backends for illustration purposes. a) S/4HANA Onpremise system over Cloud Connector and Principal Propagation b) SuccessFactors and c) S/4HANA Cloud with OAuth2 SAMLBearer Assertion security material.

Putting it all together:

Let's get our hands dirty by putting together the sequence now. The prerequisites to follow along are listed below:

Administrator privileges in the BTP subaccount where the Integration Suite subscription exists.
An IAS Tenant (with Administrator privileges) that can be coupled (read: Trusted) with the said BTP Subaccount.
Privileges to create Applications (read: IDP configurations) in Entra ID (Azure AD) and/or Okta.
Postman Client.
Backend systems to which the frontend user principal can be propagated to. Either of S/4HANA OnPrem, S/4HANA Cloud, or SuccessFactors tenant.

Step 0: Create a Service Instance for the Authorization Code grant type

Create an instance of the 'Process Integration Runtime' Service (integration-flow service plan) specifically with the authorization code grant type. You can copy the JSON snippet pasted below. Do not worry about the location of the redirect_uri. (When we get down to testing the flow, the browser will invoke the redirect_uri, but this has no consequence as the 'code' will be available for us to copy as a query parameter from the URL itself. When we test this from Postman the client, Postman does not invoke the URL. If you are curious to know, you can read about it here.) Also, make a note that we have specified refresh_token as part of the requested grant type. This will let us demonstrate the ability for clients to refresh the access token post-expiry.

{
    "grant-types": [
        "refresh_token",
        "authorization_code"
    ],
    "redirect-uris": [
        "http://localhost"
    ],
    "roles": [
        "ESBMessaging.send"
    ]
}

With the service instance created, generate a service key (example block is pasted below). Grab the clientid, clientsecret, authorizationurl, tokenurl attributes. We will need these later.

Step 1: Configure OpenID Connect based Trusted Identity Provider of SAP IAS in your SAP BTP subaccount

This step is the heart-and-soul of our approach. We will couple an SAP IAS tenant with our BTP subaccount that has the subscription of our SAP Cloud Integration (SAP Integration Suite) tenant using OpenID Connect protocol and then onboard the desired external Identity Providers (I will demonstrate Entra ID and Okta) as corporate identity providers in the IAS administration console.
Since I've documented the steps in my previous blog, I will not repeat the exact steps here. Please refer to the following sections in the linked blog.

Objective	Steps to follow from the linked blog
Couple your BTP subaccount and your SAP IAS tenant.	Steps 1-6
Configure applications (relying party) in Azure AD and Okta IDP based on OpenID Connect and SAP IAS as the callback URI.	Steps 7 - 25
Configure application in Okta with SAML Trust to SAP IAS.	Steps 26 - 33
Onboard the above Corporate Identity Provider configurations into SAP IAS.	Steps 34 - 46
configure IAS as the proxy Identity Provider and SAP BTP as the Service Provider.	Steps 47 - 52

Nevertheless, here is a summary of the main steps involved in the setup.

1. The subaccount where the Integration Suite subscription exists has a 'Trusted connection' with the OpenID Connect protocol (not SAML) to the IAS tenant.

2. The IAS tenant has a 'Corporate Identity provider' connection to Azure AD (Entra ID) via a set of Application credentials and OpenID Connect protocol.

3. Notice the 'Application' settings on the Azure side. The redirect URI has been set to the IAS tenant's '../oath2/callback' segment

4. The IAS tenant has a 'Corporate Identity provider' connection to Okta IDP via a set of Application credentials and OpenID Connect protocol.

5. Notice the 'Application' settings on the Okta side. The redirect URI has been set to the IAS tenant's '../oath2/callback' segment.

6. We will not leverage this flow in our demonstration but note that it is very much possible to use SAML bindings between the Corporate Identity Provider and IAS. The federation works exactly as OIDC.

7. Next, we want to demonstrate a dynamic / Group assertion / Role Collection based user role/authorization determination. For that note that on the Azure side, we have a group called 'IntegrationDevelopers' that contains the users who must be authorized to call the IFlow / API on the Cloud Integration side.

8. Notice how the 'groups' claim on the IAS side resolves to the value of the group from Azure.

9. Similarly, see that the target user has been assigned to the 'IntegrationSuiteDevelopers' Group in Okta.

10. Okta presents the user's 'Groups' claim to IAS that XSUAA will resolve in a later step.

11. As a last configuration step, notice that there is a RoleCollection on the BTP side (with the 'MessagingSend' role assigned) mapped to the respective groups from the source identity providers.

Step 2 & 3: Initiate the client flow.

The easiest way to demonstrate a client flow is to do so in Postman which natively supports simulating an OAuth 2.0 3-legged Authorization Code grant flow. We can break down the segments of the 3-legged flow in a browser as well. I will demonstrate both of these user agents.

Summary of the steps about to be performed in this section

Objective	Steps
Use Postman to set up Authorization Code flow with Okta Identity Provider	1-8
Use Postman to set up Authorization Code flow with Entra ID Identity Provider	9
Usage of Refresh Tokens	13-14
Use Browser to set up Authorization code flow with Identity Providers	15-18

1. Within the 'Authorization' tab in Postman, set the 'Type' to 'OAuth 2.0' and the 'Grant type' to 'Authorization Code'.

2. Enter the values for the Callback URL, Auth URL, Access Token URL, Client ID, Client Secret from the values saved in the Step 0 block above.

3. Click on 'Get New Access Token'. Make sure to turn on the 'Console' tab at the bottom to keep track of requests and responses across the wire.

4. Postman will launch the Logon pop-up from BTP's Authorization Server. Notice that you are presented with a list of Identity Providers to log into as configured in BTP's Trust Management section. Select the one that corresponds to your IAS Tenant.
Pay attention to the GET requests in the Console tab. You will see that the request to the 'authorize' resource is being redirected to the login page.

5. The system will prompt you to present the user identifier, this will serve as an input to the 'Conditional Authentication' block set in the IAS tenant to resolve which corporate identity provider to redirect to, for the user logon challenge.

6. The system determines that the challenge should come from Okta IDP for my *.sap.com user name. Please refer to the 'Conditional Authentication' screenshot to get a summary of the determination process.
In the 'Console' section, make a note of how the callbacks are handled.

Conditional Authentication section in SAP IAS

7. Okta will authenticate the user and present back the 'authorization code' to IAS.

8. Finally the client will exchange the authorization code for the access token from the configured token endpoint.

9. Let us now perform steps nos. 3-8 again, but this time let us log in with our *.outlook.com user that gets authenticated and authorized from Entra ID (Azure AD).

10. Upon inspection, you will note that the access token issued by XSUAA has the 'ESBMessaging.send' scope as determined by the 'Groups' claim presented by the source IDP. You will remember that we created a mapping for this resolution in a previous step. Also, note that the system bears a refresh_token.

11. Further, if you inspect the respective JWTs issued by Okta and Entra ID, you will see that the tokens contain the claims that represent the Groups, RoleCollections, and User Identifier info.

12. Simply go ahead and 'Use Token' to load the token to make your request.

13. Using the refresh_token -> Notice that the token will expire after a set duration (based on the 'expiry' setting). As you can see in the screenshot below, Postman detects that the available token is expired. It gives an option to 'Refresh' the token. Click on this button.

14. Make a note in the Console tab that the client POSTs to the token endpoint with the available refresh_token and the refresh_token grant_type to get a fresh access token.

15. In the next screenshots, let us perform the same set of steps in a browser. We will need to frame the URL to the /oauth/authorize endpoint. The easiest way to do so would be to copy the URL from the Postman Console we referred to before. The URL is in the format :

https://<tenant-id>>/authentiation.<dc>.hana.ondemand.com/oauth/authorize?
response_type=code&client_id=<url-encoded-client-id>&redirect_uri=<url-encoded_redirect_uri>

16. Invoke the URL in a browser.

17. After the 'login' and 'authenticate' procedures, you will see that the browser is redirected to the redirect_uri location. You can copy the 'code' parameter from the URL.

18. Go back to Postman and POST the Access Token endpoint with the grant_type set to authorization_code and the copied code and the redirect_uri. The server will respond with the access_token with the same set of attributes populated as demonstrated in Step 11.

Step 4: Integration Flow Reciever side propagation

Now that we have an access_token that can be presented to the Cloud Integration runtime (to a 'Sender Adapter'), let us put together a simple IFlow that can demonstrate the fact that the user's identity from the external identity provider can be propagated to 3 backend systems - a) S/4HANA Onpremse, b) SuccessFactors and c) S/4HANA Cloud via Principal Propagation and OAuth2SAMLBearer mechanisms respectively.

Here is a summary of the steps we intend to achieve:

Objective	Steps
Create a sample IFlow that demonstrates the user propagation sequence to 3 different types of backend systems.	1-2
Invoke S4HANA Cloud backend	3 - 7
Invoke SAP SuccessFactors backend	8 - 13
Invoke SAP S/4HANA Onpremise backend	14 - 17

1. Let's start by putting together a simple IFlow to illustrate the user propagation flow. Since we are planning to invoke with 3 backends, the quickest way to demonstrate this would be to create a Router that has 3 branches. Each with a 'Request-Reply' step for the backend type, S/4HANA Cloud, SuccessFactors, and S/4HANA OnPremise respectively.

2. The logic we will follow is that the client passes a value in a custom header named 'target' that shall determine which of the routes is to be invoked.

3. In the property sheet of the HTTP Receiver for S/4HANA Cloud backend, notice that we've used a credential named 's4hanaCloudCredentials' with the OAuth2 SAML Bearer Assertion type.

4. I will not get into the details behind how the attributes of this Security Material have been formulated. Refer to parts of this blog post for details. The points worth mentioning here are that a) we are using the target system type SAP BTP (CF) and b) the 'userIdSource' attribute is annotated for 'email' & nameIdFormat is set to 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress', thereby implying that the user identifier from our original JWT token negotiated with the corporate identity provider will serve as the user principal to be propagated.

5. Let us make a call to the IFlow URL with the access token set from step 8 described in the above section. Note that we've set the 'target' header attribute to 's4hanacloud' so that the call gets executed in the first route. We get an HTTP 200 OK and the service document as the response and there you have it! We were able to successfully propagate the user from an external identity provider and execute a call in an S/4HANA backend with the user's context.

6. How do I prove my point that the user was indeed propagated? The next two screenshots do so. Note that on the S/4HANA side, I have a 'Business User' that bears my (that is propagated from Okta) emailID. Also, note that the HTTP Call is executed with this user context and NOT with a Communication User (technical user) attached to the Communication Arrangement.

7. Further to prove my point, I execute step no. 5, this time by presenting my *@outlook.com user (that comes from Entra ID), you see that the call fails and the error description calls out that the backend was not able to resolve the presented *.outlook.com user.

8. Let us now look at the 2nd route, the one that invokes a SuccessFactors URL. We extend the same 'OAuthSAMLBearer Assertion' type with a credential named 'SFSFUserPrincipal'. On the processing tab, you will see that I'm invoking a GET Query on the JobProfile resource.

9. In the details of the Security Material, note that we've set the attributes per SuccessFactors documentation. The User ID is set for principal propagation. Like before, we've used the same nameIdFormat as set in step 4 above, and don't forget to include the apiKey attribute as well.

10. Let us now invoke the IFlow, this time around with the header 'target' set to 'sfsf'. I get back a response from SuccessFactors with the JobProfile details.

11. Again, how do we prove that the call indeed was made in the signed-in user's context? There are many ways to establish this. A simple way I followed was to put a 'proxy' layer like API Management before the call hits the SuccessFactors backend and print out the 'Bearer token' from the 'Authorization' header. Upon Base64 decoding the token, you will see that the token bears a 'sfPrinciple' attribute with the employee ID identifier.

12. Look up the employee profile of the user in question in your SuccessFactors tenant and you can verify the matching employee ID and the corresponding email address.

13. Negative testing -> If I perform the call again, this time by signing in with the email address from Entra ID you should see a 401 unauthorized exception stating that the propagated user wasn't resolved.

14. Finally, we are down to the last segment of our testing. A connection to S/4HANA On-premise. I've configured an SAP Cloud Connector and an X.509 certificate signing procedure (that is beyond the scope of this demonstration) and have dialed 'Principal Propagation' for the authentication type.

15. Invoking the client this time around with the 'target' header set to 's4hanaonpremise'. I get back a response from the server with my service document for the invoked GWSAMPLE_BASIC OData service.

16. As a quick verification step, let us go to the 'Monitor' section in the Cloud Connector and within the 'Most Recent Requests' tab, you can see a record for the 'User' that was propagated.

17. Open the LJSTrace log file and you can hunt down a log entry that corresponds to the user subject that was propagated via the short-lived x.509 certificate.

Phew!

Summary:

It is beyond doubt that 'client credentials' and 'x.509 certificate' are the two most prominent and widely popular ways to authenticate to an Integration Flow / API artifact in SAP Integration Suite, but should you have a requirement to authenticate and authorize with the client user's identity from a corporate Identity Provider, OpenID Connect support from SAP Cloud Identity Service along with the Authorization Code grant type in SAP Integration Suite provide an excellent and out-of-box approach to get your job done.

Cheers, and more power to the SAP Integration Suite Community!

SAP Secure Login Service for SAP GUI Now Supports Custom Certificate Authorities on AWS

2024-04-11T10:24:50.174000+02:00

The SAP Secure Login Service for SAP GUI solution provides your SAP GUI users with simple and secure access to their ABAP-based business applications. In March 2024, we released the long-awaited Custom Certificate Authority (CA) feature. You can now integrate your own Public Key Infrastructure (PKI) by connecting to a private CA hosted on Amazon Web Services (AWS).

With the SAP Secure Login Service for SAP GUI, you can provide end users of SAP GUI with X.509 certificates that enable single sign-on (SSO) to ABAP-based business applications. After successful authentication, the SAP Secure Login Service provisions a short-lived X.509 certificate to the Secure Login Client on the end-user desktop. This certificate is then used for SSO to the ABAP systems. In the initial scope of the solution, the SAP-managed Cloud CA was used to sign these end user certificates.

What’s new?

With the newly released feature you now have the option to integrate your own PKI by connecting your cloud-based private CA running on Amazon Web Services (AWS) to the SAP Secure Login Service. After successful authentication of the end user, your private CA issues an X.509 certificate. And the SAP Secure Login Service then returns this X.509 certificate to the Secure Login Client on the end user desktop.

How does it work?

By connecting your cloud-based private CA running on AWS, the X.509 certificates will be signed by your own customer-managed CA. The SAP Secure Login Service will just reuse your CA setup and provision the certificates to the Secure Login Client of the end users.

Configuration required for the token exchange, credentials for accessing AWS, and which AWS Private CA to be used can be configured in the administration console of SAP Secure Login Service (via the new tab “Custom CA”). This configuration is needed for secure token exchange and to ensure that only your SAP Secure Login Service subscription can be used to access your custom CA. And at the same time, that the certificates can only be used for SAP GUI SSO.

Of course, the certificates that are signed by your custom CA will look differently from the ones that are signed by the SAP Cloud Root CA. You can decide about the root, how many levels you want to have in there, and the names.

For configuration information, please refer to the documentation that is available on SAP Help Portal here:

https://help.sap.com/docs/SAP%20SECURE%20LOGIN%20SERVICE/c35917ca71e941c5a97a11d2c55dcacd/32875689a8654e0bb3c8697fb6947940.html

What are the benefits?

For compliance reasons you might not be allowed to use the SAP-managed Cloud CA to sign the end user certificates but have to use a CA that is fully under your control. With the new feature you can now integrate with your custom CA running on AWS thereby having full control how the CA is set up. For example, the root of the CA, whether it is in the AWS CA or offline, and how the signed certificates will look like.

More information

For more information about our SAP Secure Login Service for SAP GUI solution and to stay up to date on the latest developments, visit our topic page in SAP Community:

https://pages.community.sap.com/topics/single-sign-on

Identity Federation: SAP Ariba SSO with SAP Cloud Identity Services - Identity Authentication

2024-04-11T10:54:21.367000+02:00

See as well:

Table of Contents:

Setup SAP IAS Identity Provider Proxy (IdP Proxy) as Identity Provider (IdP) for SAP Ariba
SAP IAS Identity Provider Proxy (IdP Proxy) SAML Metadata Retrieval
Corporate Identity Provider (Corporate IdP) SAML Configuration to SAP IAS
Corporate Identity Provider (Corporate IdP) Metadata Retrieval
Setup SAP IAS Identity Provider Proxy (IdP Proxy) Identity Federation to Corporate Identity Provider (Corporate IdP)
Federate SAP IAS Identity Provider Proxy (IdP Proxy) Application to Corporate Identity Provider (Corporate IdP)

Setup SAP IAS Identity Provider Proxy (IdP Proxy) as Identity Provider (IdP) for SAP Ariba

SAP IAS Identity Provider Proxy (IdP Proxy) as Identity Federation is extension of Identity Provider (IdP) configuration itself. Therefore SAP Ariba acting as Service Provider (SP) Single Sign-On (SSO) needs to be setup as Identity Provider (IdP) with SAP IAS Identity Provider Proxy (IdP Proxy) as per the configuration described in the blog below:

Configuration: SAP Ariba SSO with SAP Cloud Identity Services - Identity Authentication

SAP IAS Identity Provider Proxy (IdP Proxy) SAML Metadata Retrieval

To retrieve SAML Metadata from SAP IAS:

enter the below SAP IAS URL into browser:
https://<SAP IAS tenant id>.accounts.ondemand.com/saml2/metadata?action=download
store the downloaded SAP IAS Metadata File

Corporate Identity Provider (Corporate IdP) SAML Configuration to SAP IAS

Using the retrieved SAP IAS Metadata File, the Corporate Identity Provider (Corporate IdP) authentication configuration needs to be setup.

See THIS blog (and SAP documentation) for reference of the setup of Microsoft Entra ID as Corporate Identity Provider (Corporate IdP) with SAP IAS Identity Proxy.

See Microsoft Tutorial for reference of the setup to be performed in Microsoft Entra ID.

Corporate Identity Provider (Corporate IdP) Metadata Retrieval

Once the Corporate Identity Provider (Corporate IdP) SAML Configuration to SAP IAS setup (referenced above) is performed, download the Corporate Identity Provider (Corporate IdP) Metadata File.

In case of Microsoft Entra ID, follow the step 9. from the Microsoft Tutorial to download the Corporate Identity Provider (Corporate IdP) Metadata File as Federation Metadata XML.

Setup SAP IAS Identity Provider Proxy (IdP Proxy) Identity Federation to Corporate Identity Provider (Corporate IdP)

To setup the Identity Federation for SAP IAS Identity Provider Proxy (IdP Proxy) to Corporate Identity Provider (Corporate IdP😞

enter the SAP IAS Administration Console via https://<SAP IAS tenant id>.accounts.ondemand.com/admin
navigate to Application & Resources -> Identity Providers -> Corporate Identity Providers -> [Create]

enter the Display Name and choose the Identity Provider Type

navigate to SAML 2.0 Configuration -> [Browse...] and upload the Corporate Identity Provider (Corporate IdP) Metadata File

SAML 2.0 configuration is pre-set out of the uploaded Corporate Identity Provider (Corporate IdP) Metadata File
hit [Save]

Federate SAP IAS Identity Provider Proxy (IdP Proxy) Application to Corporate Identity Provider (Corporate IdP)

Once the Identity Federation between SAP IAS Identity Provider Proxy (IdP Proxy) and Corporate Identity Provider (Corporate IdP) is established, the Application representing the SAP Ariba Service Provider (SP) in SAP IAS Identity Provider Proxy needs to be setup to federate to this Corporate Identity Provider (Corporate IdP).

(The SAP Ariba Service Provider (SP) Application was created as part of the first chapter of this blog and referenced to the steps in Configuration: SAP Ariba SSO with SAP Cloud Identity Services - Identity Authentication.)

navigate to Application & Resources -> Application -> application representing SAP Ariba e.g. Ariba Tenant: <SAP Ariba tenant id> -> Conditional Authentication -> choose the Corporate Identity Provider (Corporate IdP) name

hit [Save]

In case you are reading this line, you have successfully configured the Single Sign-On (SSO) between SAP Ariba as Service Provider (SP) and SAP IAS as Identity Provider Proxy (IdP Proxy) with Identity Federation to Corporate Identity Provider (Corporate IdP)!

See as well:

Identity Provisioning Documentation Joined the Family of SAP Cloud Identity Services

2024-04-11T11:37:11.801000+02:00

SAP Cloud Identity Services consolidated the documentation for Identity Authentication, Identity Provisioning, Identity Directory and Authorization Management. They now come under one product name, on a unified SAP Help Portal page, accessible through a single link.

The integration of Identity Provisioning functionality into the SAP Cloud Identity Services administration console, formerly known as the Identity Authentication admin console, has streamlined the process.

What’s been changed?

Identity Authentication product documentation has been rebranded as SAP Cloud Identity Services. With this change, SAP Cloud Identity Services now becomes the home of Identity Provisioning features for the Cloud Identity Services infrastructure, joining the already existing Identity Directory and Authorization Management.
The product documentation for Identity Provisioning has been rebranded as Identity Provisioning Service in the Neo Environment. It will only cover features for the Neo environment until its deprecation (as previously announced).
You can find the release notes for Identity Authentication, Identity Provisioning, Identity Directory and Authorization Management under the single component Cloud Identity Services by following this link. If there are new features for IPS in the Neo environment, they can still be found under Identity Provisioning component for Neo at this link.

What does this mean for you?

Unified Access – You get all the information you need in one single guide. No more switching between product documentations. It comes as little surprise that Identity Authentication ranked among the most frequently searched and visited topics within the Identity Provisioning documentation.

No URL Changes – You access the Cloud Identity Services documentation from the same URL you used to access the Identity Authentication one. You access the Identity Provisioning Service in the Neo Environment documentation from the same URL you used to access the Identity Provisioning documentation.
Simplicity – We believe reading and navigating through the Identity Provisioning content has become easier now that we have separated and placed the documentation relevant to each specific infrastructure or environment.

Bookmarked URLs of topics relevant for Cloud Identity infrastructure will redirect you to the common documentation.

Here are some examples of what you can find where:

Feature	SAP Cloud Identity Services	IPS in the Neo Environment
Jobs	Read Provisioning Job Resync Provisioning Job Simulate Provisioning Jobs Validate Provisioning Jobs Run Provisioning Jobs via API	Only read and resync jobs are supported. Read Provisioning Jobs Resync Provisioning Jobs
Logs	Monitor Real-Time Logs	Real-time logs are not supported.
Transformations	Working with Graphical Editor Manage Transformations History	Graphical editor and managing transformation history are not supported.
Connectors	Local Identity Directory	Local Identity Directory connector is not supported.
Migration	Not applicable	Migrate Identity Provisioning Bundle Tenant

Consistent structure - The documentation of SAP Cloud Identity Services and Identity Provisioning follow the same service guide template. You can easily identify IPS-related concepts and supported systems (connectors), operations and logs in the common documentation:

We believe the newly released documentation will be easy to navigate, familiar, and consistent for you. If anything appears unclear, please do reach out. In the never-ending quest for quality, there is always room for improvement.

SAP Successfactors Implementation and Maintenance in Projects in 2024

2024-04-16T12:51:24.164000+02:00

Introduction:

I am new to SAP SuccessFactors and continuously honing my skills and knowledge through daily learning endeavors. In this blog post we will talk about the recent updates in SAP SuccessFactors Platform and Security enhancements and how to manage the SF landscape in 2024 from platform perspective

Important Information:

For New SuccessFactors Customers:

New SuccessFactors tenants created after December 9th 2022, IAS is automatically deployed. For new customers SAP is not providing the option to implement it without IAS|IPS.

For more details, please refer SAP note : 3097769 - IAS / IPS - Is IAS implementation mandatory for all SuccessFactors customers?

For Old SuccessFactors Customers:

Upon expiration of SuccessFactors SSO signing certificate on June 2, 2025, if customers do not migrate to IAS or make any changes, the User authentication and Single Sign-On functionalities will not work. Recommendation is to take action before June 2025 to make sure your SSO functionality works fine.

For more details, please refer SAP note: 2791410 - Integrating SuccessFactors with Identity Authentication IAS through the Upgrade Center

Steps to manage landscape:

For Greenfield implementation projects:

Below steps are already performed by SAP

IAS is integrated with SuccessFactors Application.
IPS configuration to sync users from SF to IAS is also partially completed. Source System as SF and Target System as IAS is created automatically.
IPS configuration to sync users from SF to People Analytics is also partially completed. Target System as People analytics is also completed.

Below steps are required to be done by customer

Enable sync job in IPS to sync users from SAP SF to IAS. Update transformation code if required.
Enable sync job in IPS to sync users from SAP SF to People analytics.

Let's see how it's done.

Open IPS tenant and in Properties - Edit the filter to sync one user.

Property name: sf.user.filter

Value: status eq 'active' and username in 'sf_username1_placeholder','sf_username2_placeholder'

Put the username of users whom you want to sync as part of your testing and trigger the sync job.Once Testing is completed, update the values as shown in the screenshot.

To test the connectivity, first trigger the simulate job (to check connectivity) and then run the Read or FullSync job to actually sync the users.

Post testing, Schedule the read job to be triggered in specific time intervals.

As this source system is configured in both the target systems ( IAS and People Analytics), It will start syncing the users to both the target environments.

Enhanced Security and Maintenance of Certificates:

Connectivity between SAP SF - IPS - IAS is done through certificates

In IPS - Authentication Property is set as ClientCertificateAuthentication

This certificate is generated in IPS and is required to be uploaded in Source system - SAP SuccesFactors and in Target System - IAS. This certificate is renewed every year and this activity is required to be performed once a year.

For Source System:

Certificate can be downloaded from here:

Certificate can be uploaded in SAP SuccesFactors in Security Center:

For Target System:

Certificate can be downloaded from here:

Upload the certificate in IAS:

Conclusion:

In this blog post we have learned how to manage the SuccessFactors landscape for Greenfield projects in 2024.

Configure Custom SAP IAS tenant with SAP BTP Kyma runtime environment

2024-04-20T15:41:26.519000+02:00

This brief is to showcase how to get this done using a SAP BTP trial account.

Albeit, the entire procedure is well documented in SAP Help portal, namely under Configure a Custom Identity Provider for Kyma, the missing piece of the puzzle is the configuration of the identity provider application.

Any OIDC provider can be used as a custom OIDC provider with a kyma cluster. However, SAP BTP platform makes it both simple and affordable with the Always Free SAP Cloud Identity Authentication services.

From experience, this is is the most error-prone part of the procedure.
In order to alleviate the pain and burden of creating a SAP IAS service provider application I have prepared automation scripts that can be used entirely programmatically either from a kyma environment itself or directly from a BTP subaccount level.

Let's see how.

Table of Contents

prepare subaccount for kyma runtime with a custom IAS tenant

establish BTP subaccount trust with a custom SAP IAS tenant.

Kyma Environment.

Accessing Kyma Dashboard

PS.

1. The SAP IAS service provider application automation script for those you'd like to run it directly from a kyma dashboard.

A hint: You may want to replace all the placeholder values with the shoot name of a kyma cluster.

# Source: skr-easy/templates/binding-ias.yaml
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: skr-ias-binding
  labels:
    app.kubernetes.io/name: skr-ias-binding
spec:
  serviceInstanceName: '<serviceInstanceName>' ##fee3078
  externalName: '<externalName>' ##fee3078
  secretName: skr-ias-binding-secret
  parameters:
    credential-type: "NONE" 
  parametersFrom: []
---
# Source: skr-easy/templates/service-ias.yaml
apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: '<name>' ##'fee3078'
  labels:
    app.kubernetes.io/name: '<label>' ##'fee3078'
spec:
  externalName: '<externalName>' ##fee3078
  serviceOfferingName: identity
  servicePlanName: application
  parameters:
    name: '<name>'                     ##'fee3078' ### name of the application created in IAS or the service instance id
    display-name: '<display-name>'     ##'shoot-name-fee3078' ### display-name of the application created in IAS
    home-url : '<home-url >'           ## 'https://$BTP_SUBDOMAIN.fee3078.kyma.ondemand.com'
    user-access: public ## allows for self-registration

    oauth2-configuration:
      grant-types:
        - authorization_code
        - authorization_code_pkce_s256
      token-policy:
        token-validity: 3600
        refresh-parallel: 3
        access-token-format: default

      public-client: true ## if set to true, enables PKCE flow for the application, where the client does not need to provide a credential.
      redirect-uris:
        - 'https://dashboard.kyma.cloud.sap'
        - 'http://localhost:8000'
    subject-name-identifier:      ## https://help.sap.com/docs/identity-authentication/identity-authentication/configure-subject-name-identifier-sent-to-application?locale=en-US
      attribute: mail ##userUuid
      fallback-attribute: none ##uid

    default-attributes:    ## https://help.sap.com/docs/identity-authentication/identity-authentication/configure-default-attributes-sent-to-application?locale=en-US
    
    assertion-attributes:  ## https://help.sap.com/docs/identity-authentication/identity-authentication/configure-user-attributes-sent-to-application?locale=en-US
      email: mail
      groups: companyGroups
      first_name: firstName
      last_name: lastName
      login_name: loginName
      mail: mail
      scope: companyGroups
      user_uuid: userUuid
      locale: language

2. Let's assume one needs to provision a kyma cluster with a custom IAS from the start.
In this case the SAP IAS service provider application must be created before the kyma environment is enabled.

SAP IAS service instance application plan parameters for those who need to enable a kyma cluster configured with a custom SAP IAS from the get-go:

{
        "name": "quovadis",
        "display-name": "quovadis",
        "user-access": "public",
        "oauth2-configuration": {
            "grant-types": [
                "authorization_code",
                "authorization_code_pkce_s256"
            ],
            "token-policy": {
                "token-validity": 3600,
                "refresh-parallel": 3,
                "access-token-format": "default"
            },
            "public-client": true,
            "redirect-uris": [
                "https://dashboard.kyma.cloud.sap",
                "http://localhost:8000"
            ]
        },
        "subject-name-identifier": {
            "attribute": "mail",
            "fallback-attribute": "none"
        },
        "default-attributes": null,
        "assertion-attributes": {
            "email": "mail",
            "groups": "companyGroups",
            "first_name": "firstName",
            "last_name": "lastName",
            "login_name": "loginName",
            "mail": "mail",
            "scope": "companyGroups",
            "user_uuid": "userUuid",
            "locale": "language"
        }
}

As the SAP IAS service provider OAuth2 application must be configured with the authorization code with PKCE grant type, one needs to provide the following service bindings parameters:

 {
    "credential-type": "NONE"
 }

The resulting binding will contain both the clientid and the issuer url. These values can be used directly with the kyma cluster provisioning wizard.

{
    "clientid": "f61*************",
    "url": "https://***.trial-accounts.ondemand.com",
}

From now on, one can update/create the kyma environment settings, either from the BTP cockpit or using the btp cli with the below json parameters (saved to a local config.json file)

{
    "administrators": [
        "email1@domain.com",
        "email2@domain.com",
        "emailN@domain.com"
    ],
    "oidc": {
        "clientID": "f61********************",
        "groupsClaim": "groups",
        "issuerURL": "https://***.trial-accounts.ondemand.com",
        "signingAlgs": [
            "RS256"
        ],
        "usernameClaim": "sub",
        "usernamePrefix": "-"
    },
    "name": "quovadis"
}

Eventually, the below script shows how to create a new kyma environment using btp cli with BTP Trial account, namely:

btp create accounts/environment-instance --display-name quovadis --environment kyma --service kymaruntime --plan trial --parameters config.json

Creating an environment instance for subaccount e691b16b-**********...

environment id:     B1A10B19-************
environment name:   quovadis
environment:        kyma
landscape:          
state:              CREATING
state message:      Creating environment instance.

Command runs in the background. 
Use 'btp get accounts/environment-instance' to verify status.

OK


btp list accounts/environment-instance

Showing environment details for subaccount e691b16b-*************:

environment name   environment id                         environment type   state   state message                   landscape   
*******trial       AA23C91E-************   cloudfoundry       OK      Environment instance created.   cf-ap21     
quovadis           B1A10B19-************   kyma               OK      Environment instance created.               


OK

and then how to dispose of it:

btp delete accounts/environment-instance B1A10B19-**************
Do you really want to delete the specified environment instance and all content? [no]> yes

Deleting environment instance B1A10B19-******** and all its data in subaccount e691b16b-***********...

environment name:   quovadis
environment id:     B1A10B19-***************
environment type:   kyma

Command runs in the background. 
Use 'btp list accounts/environment-instance' to verify status.

OK

Alternatively, a kyma environment update can be performed as well, for instance:

btp update accounts/environment-instance B1A10B19-******** --plan trial --parameters config2.json

Updating environment instance with ID B1A10B19-***********

OK

Please note it is not possible to amend the list of modules via a kyma environment update.

Streamlining User Provisioning from IBM Verify to SAP Cloud Identity Services

2024-05-08T12:57:02.652000+02:00

SAP Cloud Identity Services (CIS), part of SAP BTP, can be used to integrate Identity Access Management (IAM). In our last blog, we discussed the integration of SAP Cloud Identity Services (CIS) with IBM Security Verify, and now we're taking the next step in this integration. User provisioning is the process of setting up new user accounts in a system or application. In this blog, we will explore a common use case - - transitioning user provisioning from IBM Verify to SAP Cloud Identity Services, and how this transition can streamline operations and enhance security.

The Challenge of User Provisioning

User provisioning is the process of granting and controlling access to resources within an organisation’s information technology infrastructure. Historically, on-boarding or off-boarding users has been a laborious and time-consuming procedure that frequently required numerous processes across multiple systems. As businesses embrace cloud solutions, the complexity of user provisioning has grown, necessitating automated and integrated approaches.

Transitioning from IBM Verify to SAP Cloud Identity Services

IBM Verify is a comprehensive identity and access management system that includes multi-factor authentication (MFA) and adaptive access control, while SAP Cloud Identity Services offers identity lifecycle management, single sign-on (SSO), and access governance features. Integrating these two systems can help organisations automate and streamline user provisioning operations, while also improving security and user experience.

How does it work?

The diagram shows that IBM Security Verify acts as a central user management system. It creates user accounts and manages their attributes, and also provisions them (or creates them) in SAP Cloud Identity Services, potentially syncing relevant user attributes. Selected attributes from Verify are mapped to specific target attributes in SAP Cloud Identity Services, ensuring consistent user information across both systems. SCIM, a standardised protocol, enables communication between Verify and SAP Cloud Identity Services. On the left side of the diagram, IBM Security Verify acts as a SCIM server, receiving requests for user management and then modifying the target directory as needed. This streamlines user creation and ensures consistent user information across both systems.

Prerequisites

SAP Cloud Identity Services (for trial instance check this link)
IBM Security Verify (for trial instance check this link)
A smartphone with IBM Security Verify App

Configurations and Settings in IBM Security Verify and SAP Cloud Identity Services

Log into IBM Security Verify as an administrator

When a user logs in, the home screen as shown below will be displayed.

On the left panel, click on "Applications" under "Applications". On the right side of the screen, there is an “Add application” button. Click on it.

Fill in the necessary details under “General” section as below and save the details.

Before we go further, let’s log into SAP BTP account and you will be navigated on SAP BTP Cockpit. As suggested below, navigate to the “Instances and Subscriptions” tab which is under “Services.”

You have to enable the cloud identity services application.

Once enabled, it will look as below. Now, click on Cloud Identity Services application and you will be redirected to the login screen of the SAP authentication screen as shown below.

After a successful login, you can see the home screen of Cloud identity Services. Go to the “Identity Providers” as highlighted below :

Click on the Corporate Identity providers and create new identity provider.

Once the new identity provider is successfully added, click on the identity provider type and select SAML 2.0 compliant, as shown below:

Go to the SAML configuration section and fill in the information as shown below:

You can browse the “Metadata” file from your device once you download it from IBM Security Verify dashboard. Go to the “Sign on” section of the application and on the right side of the screen, download the file from the given URL and upload the same in SAP Cloud Identity Services as highlighted below:

Click on the Trusting application section and add SAP BTP trial subaccount.

Establish the trust configuration, which is under the “Security” section for the cloud identity application as shown in the below screenshots.

You will see the below steps once you click on establish trust. In the first step, choose tenant and click on the next.

After selecting a tenant, choose domain for your SAP Cloud Identity Services application.

Click on the next button and configure parameters as shown in the below screenshot.

Click on the next button and review the setup that you have done while establishing the trust. Finally, click on the finish button and save the details.

Once done, you can see the trust new active trust configuration as shown below:

Now go back to IBM Security Verify and click on “Sign-on” section, then select “Use metadata” checkbox. It will allow us to upload the metadata file which we have downloaded from SAP BTP as shown below:

Upload the metadata file which you have recently saved on your device to IBM Verify dashboard.

Now go to the “Account lifecycle” tab and add SCIM URL, Username and password detail as shown in below image. You can get all the details from SAP Cloud Identity Services application page.

To get SCIM URL, go to SAP CIS and get the URL details from the browser and add “SCIM” at the end of URL.

After adding the above details, scroll down and you can see “Attribute mapping” section. Click on the checkbox for which attribute you want to map from IBM Verify to SAP CIS and want to keep updated. Here we have checked email. Save this detail once changes are completed.

We have completed the configurations in IBM Security Verify and SAP Cloud Identity Services. Let’s add user with attribute into Verify and check if it is mapped to Cloud Identity Users dashboard.

Go to the Users tab under the “Directory” section on the left side of the verify dashboard and click on the “Add User” button as shown in below screenshot.

Fill out the necessary information for the user as mentioned in the below image and click on the “Save” user tab.

Scroll down and you can add more detail about the user. Here we have added an email ID, mobile number and user company details.

Once done, click on the Save button and the user detail will be saved.

Open the Cloud Identity Services application and go to the user section to check whether the newly-created user from Verify is mapped.

Click on the “Instance and subscription” section from the “Services” section on the left menu, and once the application list is shown, click on the Cloud Identity Services application as shown below.

When the new application is loaded, click on the “User Management” tile and all the user list will be displayed.

As you can see in the below screenshot, a new user is created, which is added from Verify and mapped into SAP Cloud Identity Services. Also, the user detail is mapped into Cloud Identity Services.

Conclusion

Effective user provisioning is critical to maintaining security, compliance, and operational efficiency. Centralising identity management, improving security, and streamlining administration activities enables organisations to successfully manage user identities and access controls across their entire IT infrastructure. Embracing integrated identity management solutions is more than just convenient - - it is a strategic need for businesses looking to flourish in an increasingly linked and security-conscious environment.

More information:

Refer to our another blog on SAP Cloud Identity Service integration with IBM Security Verify.

If you have any question or query about SAP BTP please refer to SAP Community and for any question or query about IBM Security Verify refer to IBM Security Verify Community

Enabling SAML Single Sign-On for SAP S/4 HANA and SAP BTP Apps using the same SAP IDP

2024-05-08T17:48:21.660000+02:00

co-author: santosh_kumar97

Introduction

The SAP Cloud Identity Services (SCI) are the dedicated cloud services that provide functionalities for authentication & single sign-on and identity lifecycle across SAP solutions. SCI includes the Identity Authentication (IAS), Identity Provisioning (IPS), Identity Directory (IdDS) and soon also the Authorization Management services (AMS).
In this blog, we will be using the Authentication and SSO feature of the Cloud Identity Services to show how apps built across multiple platforms, e.g: SAP BTP and SAP S4 HANA, can use a single user to login and navigate seamlessly. Cloud Identity Services tenant will be used as an IDP(SAP Identity Provider).

Overview

Establish Trust between S4 HANA and Cloud Identity Services Tenant
Establish 'Trust' between the SAP BTP system and Cloud Identity Services Tenant
Testing the SAML Single Sign-On

Establish Trust between S4 HANA and Cloud Identity Services Tenant

Firstly we need to extract the SAML metadata from S4 HANA system. To achieve this, we go to Transaction:SAML2
Choose "Create SAML 2.0 Local Provider".
Give a provider name in the dialog box that appears.
In the Service Provider Settings, Choose selection mode: "Automatic", since we have only 1 Identity Provider connected and we do not want to choose an Identity Provider every time.
Once we are done configuring the Local Provider, we will extract the SAML2 metadata using the "Metadata" button. Store this file for later use in the Cloud Identity Services Tenant.

We will leave the S4 configuration for now and return later. We move to the Cloud Identity Services for the configurations.
Logon to the Cloud Identity Services tenant and extract the SAML configuration.
Get the 'Signing Certificate'

To extract the Signing Certificate, copy the 'Certificate Information' to a text file and save it as *.cer file. Then you can use a 'Keystore Explorer' app or something similar to create a proper certificate.Store this certificate in your local folder.
Incase of KeyStore Explorer, open KeyStore Explorer, then click on 'Examine Certificate'. Choose the .cer file created above and click on 'Examine'. Then Click 'Export'. This signing cretificate will be used later when configuring in the S4 system.
Now let's create an application in Cloud Identity Services for our S4 HANA system. The purpose of creating this application is to establish the Trust between Cloud Identity Services tenant and S4 HANA system.
Go to "Applications and Resources" tab in the Cloud Identity Services and choose "Applications". Then click on "Create Application".Give a Display Name; Type as "SAP on-premise Solution" and create.
Now under SAML 2.0 configuration, we upload the metadata.xml file which we retrieved from the S4 system in step 5.
Once we upload the metadata file, everything gets auto-populated.
Set all the switches to ON state.

In the section "Subject Name Identifier" please choose "Identity Directory" and value as "Email" because we will use Email for authentication.
Let's continue the SAML2 configuration in S4, by providing the metadata xml that we got from theCloud Identity Services system in step 6.
The process for that is we choose the 'Trusted Providers' tab and click on 'Add'-> 'Upload metadata File'
We go through a series of steps now.

Upload the metadata.xml file that we downloaded from Cloud Identity Services Tenant.

Upload the Signing Certificate that we created in step 7.

For better security choose SHA-256 instead of SHA-1 in Signature and Encryption.
Click on next and finish all the sections.
Now click on 'Edit', then 'Add' and then select the 'Unspecified' and save the settings.
Click on Enable to Active the Config.
Goto Transaction SICF , enter the service name or external alias example /sap/bc/ui2/flp and open the service.

Double-click on the service to open it.
Select Logon Data tab. Choose the Alternative Logon Procedure and set SAML Logon at 1 and Save.

We create the url for this service as follows https://<HOST>:<PORT>/sap/bc/ui2/flp?sap-client=<CLIENT>

Establish Trust between SAP BTP and Cloud Identity Services Tenant

Login to your SAP BTP sub-account.
Go to tab 'Trust Configuration'.

Download the SAML metadata for the BTP system and create new SAML configuration.
We create a new SAML Trust Configuration by uploading the SAML metadata of the Cloud Identity Services system. Click on save once the metadata is uploaded.

Once the trust is established on the BTP side, it will be shown as follows.
We now configure Trust on the Cloud Identity Services Tenant side. To achieve this we will be creating an application on the Cloud Identity Services system and uploading the SAML metadata file of the BTP sub-account downloaded in step 1.

In the SAML2.0 configuration, we upload the metadata file and save.

Enable all Signing options

For Subject Name Identifier, give 'Identity Directory' and 'Email', then 'Save'.

We are done with the Trust establishment of Cloud Identity Services and BTP.

Testing the SAML Single Sign-On

Now, it's time to check if our configurations work.

Let's open the browser in Incognito mode.
Enter the service url of the S4 HANA application that we retrieved from the Step 17 of S4 Trust establishing.
For our use case, we have chosen the flp app url.
On Enter, the url routes to our Cloud Identity Services login url, asking for credentials from our IDP.
Remember, the users should be maintained in the IDP prior to logging in.
Enter your credentials and click on 'Continue'.

And Voila! You are logged in using your Cloud Identity Services credentials.
Now to test the Single Sign-On spanning multiple environments, let's take an application from our BTP environment, which has Cloud Identity Services enabled.
We will open a new tab, beside the S4 app that we are already logged-on and open the BTP app as well. On Enter, we are routed to the login page, with 2 options, default IDP and Cloud Identity Services IDP. We will choose the Cloud Identity Services IDP for login.

Lo and Behold!! We are logged in, without entering any more credentials.

Identity Access Management (IAM) Reference Architectures 2024

2024-05-10T17:20:21.397000+02:00

Identity Access Management Reference Architectures in 2024

We are happy to share with you that we just released an update to our reference architectures (2024 version).

The latest version is published in SAP Discovery Center along with further links to our documentation and to related missions. We want to support you trying out easily what we describe.

If you are new to this topic, consider reading my older blog post about Cloud leading Identity Lifecycle from 2021. The 1st chapter is still valid to start with - although it's 3 years old 🙂

We have an updated version of the SAP Secure Operations Map which allows you to verify your security requirements and map them to the regional requirements like NIST or BSI.
The Secure Operations Map contains in the application layer the three main IAM pillars that are now described in the SAP Discovery Center:

Authentication flows

Authorization flows as part of the identity lifecycle

Identity Lifecycle flows

Please read them and we can use this community to discuss.

If you want to know more about the SAP Cloud Identity Services I recommend this blog post.

PS: Yes, we are already working on an integrated architecture which considers SAP Access Control - but we need a bit more time.

[SSO] [SF] (Single Sign-On) for SAP SuccessFactors

2024-05-11T06:44:44.370000+02:00

IAS Tenant preparation: Log onto Identity Authentication service

Navigate to Identity provisioning > Source > Properties > sf.user.filter make it (active eq "true")
Navigate to Identity provisioning > Source > Outbound Certificates and make sure that the certificate is valid, if not generate a new one and delete the old one and activate the automatic generation
Go to Identity provisioning > Target > Outbound Certificates and make sure that the certificate is valid, if not generate a new one and delete the old one and activate the automatic generation

Note: If the IAS tenant links were not provided from SAP, you can activate from the Upgrade Center, and after completing the configuration, testing and activation will be done again from the Upgrade Center

Created trust between Azure Active Directory and Identity Authentication service

Step 1: Download Identity Authentication service tenant metadata

Navigate to Applications and resources > Tenant Setting > Single Sign-On > SAML 2.0 Configuration and download the IAS Meta data file

Download the metadata file.

Step 2: Create enterprise application in Azure Active Directory

Navigate to the Enterprise applications, Click New application.

Azure Active Directory has templates for a variety of applications, one of them is the SAP Cloud Platform Identity Authentication Service. Search for this and select it.

A new column on the right side will appear to give the application a name. Give the application a name and click Add.

Go to Single sign-on and select SAML as Single-Sign On method.

STEP 3: Upload the IAS tenant metadata file you get from the step 1

Select the application you just created, Click Upload metadata to upload the metadata file from Identity Authentication service.

All the details are now taken from the metadata file. There’s nothing to do for you other than saving the details. Therefore, click Save.

STEP 4: Download single sign-on metadata from Azure Active Directory

Download the federation metadata as shown below.

With this information we can setup the trust between Azure Active Directory and Identity Authentication service.

Step 5: Create corporate identity provider in IAS

Go back to IAS and navigate to Identity provider > Create > Microsoft ADFS / Entra AD (SAML 2.0) Type

STEP 6: Upload Azure Active Directory federation metadata file

Click SAML 2.0 Configuration and to upload the recently downloaded federation metadata from Azure Active Directory.

Choose the file from your local file system.

All fields below are automatically going to be filled due to the information provided through the uploaded file.

Click Save at the top of the page.

STEP 6: Add a new user in the Users and groups Microsoft Azure application

Go back to your overview of enterprise applications in Microsoft Azure AD and click your application. Add a new user by clicking Add user in the Users and groups submenu, as shown on the screenshot.

By hitting the result tile, you select the user, which should appear under Selected members panel. Finish your user assignment with clicks on Select and Assign.

Congrats Now you created trust between Azure Active Directory and Identity Authentication service.

IAS Tenant Final Preparation:

Navigate to Identity provisioning > Source > Jobs and run now read job to get all users from SF then schedule the job for future new hires.

Navigate to Applications and resources > Applications > SuccessFactors > Conditional Authentication and create a rule for all domains you need it to access the system from the identity provider you created... this step will define the domains witch will access as SSO, any other domain will access from the default identity provider.

Set the Default Identity Provider as Identity Authentication.

Navigate to Identity provider > Identity Federation > switch On Use Identity Authentication user store and Switch On User Access

Now you can test and be sure that the user you are try to test with is already added to the SF tenant.

Hope you enjoy the process.

Thanks

Ahmed Aranda

Configuration: SAP Business Network SSO with SAP Cloud Identity Services - Identity Authentication

2024-05-15T16:02:00.238000+02:00

See as well:

Table of Contents:

SAP Business Network Single Sign-On (SSO) Overview
- SAP Business Network Access
  - SAP Business Network Credentials Access (SSO Disabled)
  - SAP Business Network SSO Access
  - SAP Business Network SSO Access via IdP-Initiated URL
  - SAP Business Network SSO & Credentials Access
SAP Business Network Single Sign-On (SSO) Setup
- SAP IAS SAML Metadata Retrieval
- SAP Business Network SAML Metadata Retrieval
- SAP IAS SAML Authentication Configuration
- SAP Business Network User Configuration
- SAP Business Network SAML Authentication Configuration (non-self-service)

SAP Business Network Single Sign-On Overview

Note: Single Sign-On (SSO) is supported only for SAP Business Network Buyer access (SAP Business Network Supplier access is not supported).

SAP Business Network Access

SAP Business Network can be accessed via https://service.ariba.com

To access SAP Business Network as Buyer, navigate to [Buyer] button or directly navigate to https://service.ariba.com/Buyer.aw

To access the SAP Business Network as Buyer, enter the Buyer user login name and hit [Next]. Based on the SAP Business Network Buyer account SSO setup, one of below login screens will appear.

SAP Business Network Credentials Access (SSO Disabled)

In case SAP Business Network Single Sign-on (SSO) for Buyer account is disabled, login screen to enter the SAP Business Network password is displayed.

SAP Business Network SSO Access

In case SAP Business Network Single Sign-on (SSO) for Buyer account is enabled with SAP Business Network credentials access is disabled, configured SSO login screen to enter the SSO credentials is displayed (e.g. the SAP IAS login screen in case the SSO is configured with SAP IAS).

SAP Business Network SSO Access via IdP-Initiated URL

With the assumption that the SAP Business Network SSO is enabled with SAP IAS as per this blog instructions, you can access SAP Business Network instead of https://service.ariba.com link, by following the IdP-Initiated URL:

https://<SAP IAS tenant id>.accounts.ondemand.com/saml2/idp/sso?sp=ANxxxxxxxxxxx-T&index=1

Using this approach, you can skip one step, which is providing the SAP Business Network user id and login directly within your SAP IAS login credentials.

SAP Business Network SSO & Credentials Access

In case SAP Business Network Single Sign-on (SSO) for Buyer account is enabled together with SAP Business Network credentials access, login screen to enter the SAP Business Network password or [Sign in with SSO] choice is displayed.

SAP Business Network Single Sign-On (SSO) Setup

SAP IAS SAML Metadata Retrieval

To retrieve SAML Metadata from SAP IAS:

enter the below SAP IAS URL into browser:
https://<SAP IAS tenant id>.accounts.ondemand.com/saml2/metadata?action=download
store the downloaded SAP IAS Metadata File

SAP Business Network SAML Metadata Retrieval

Note: Retrieval of SAP Business Network SAML Metadata is not self-service and needs to be requested via case opened against SBN-AN-LOG component. This blog instructions are bypassing the SAP Business Network SAML Metadata retrieval and instead it provides manual steps of setting the SAP Business Network Buyer Account in SAP IAS.

To retrieve the SAP Business Network signing certificate navigate to https://support.ariba.com/item/view/192337 and download Current Certificate – RSA certificate for service.ariba.com and store it as SAP Business Network Signing Certificate File

SAP IAS SAML Authentication Configuration

Prerequisites:

SAP IAS user added as Administrator to SAP IAS (Users & Authorizations -> Administrators -> [Add])
Retrieve SAP Business Network Buyer Account ANId (e.g. ANxxxxxxxxxxx-T)
- Replace xxxxxxxxxxx with your SAP Business Network Buyer Account AN Id

Note: SAP Business Network SSO setup requires the IdP-Initiated SSO to be enabled in SAP IAS.

To enable IdP-Initiated SSO in SAP IAS:

enter the SAP IAS Administration Console via https://<SAP IAS tenant id>.accounts.ondemand.com/admin
navigate to Application & Resources ->
Application & Resources -> Tenant Settings -> Single Sign-On -> IdP-Initiated SSO

To configure SAP IAS SAML Authentication with SAP Business Network:

enter the SAP IAS Administration Console via https://<SAP IAS tenant id>.accounts.ondemand.com/admin
navigate to Application & Resources -> Application -> [Create] to create Application for SAP Ariba as Service Provider (SP)
- Enter the Display Name, choose SAP Ariba solution as Type, SAML 2.0 as Protocol Type and hit [Create]

navigate to SAML 2.0 Configuration and enter:
- Name <SAP Business Network Buyer Account AN Id> (e.g. ANxxxxxxxxxxx-T)
- Assertion Consumer Service Endpoints
  - Index 0: https://service.ariba.com/Buyer.aw/ad/relaySAML?anid=ANxxxxxxxxxxx-T
  - Index 1: https://service.ariba.com/Buyer.aw/ad/remoteLogin?anid=ANxxxxxxxxxxx-T
- Signing Certificate
  - upload the downloaded SAP Business Network Signing Certificate File
- Signing Options
  - Sign authentication responses -> true

hit [Save]

navigate to Subject Name Identifier and set the Primary Attribute Value to Login Name and hit [Save]

Note: Subject Name Identifier setting can vary based on the customer user setup in SAP IAS. The property chosen in the Subject Name Identifier in the user profile in SAP IAS shall hold the very same value as the Corporate Username of the user in SAP Business Network.

navigate to Users & Authorizations -> User Management -> and specific user SAP IAS Login Name needs to match user SAP Ariba UniqueName

SAP IAS User Profile:

SAP Business Network User Profile:

SAP Business Network User Configuration

Note:

Navigate to SAP Business Network Buyer account Settings -> Users -> Manage Users

Actions -> Edit -> Corporate Username

SAP Business Network SAML Authentication Configuration (non-self-service)

Note: SAP Business Network Single Sign-On (SSO) configuration is not self-service and needs to be requested as per the instructions below.

Create case against SBN-AN-LOG component providing below details:

SAP Business Network Buyer Account Id (e.g. ANxxxxxxxxxxx-T)
SAP IAS URL https://<SAP IAS tenant id>.accounts.ondemand.com
SAP IAS Metadata File
Disable SAP Business Network Login: Yes/No
SAP IAS User Profile field value for SAP IAS for SAP Business Network Admin User (e.g. I0****6 - this needs to match the SAP IAS user profile property value, which is set as Subject Name Identifier)
- SAP Business Network Admin User is not maintained in the list of the users in SAP Business Network and thus his Corporate Username cannot be set, therefore the SAP IAS Login Id shall be setup extra and passed as this setting

SAP personnel as part of the case execution will apply below setting in the SAP Business Network:

Assertion Issuer: SAP IAS URL (e.g. https://<SAP IAS tenant id>.accounts.ondemand.com
Corporate User ID: SAP IAS User Profile field value for SAP IAS for SAP Business Network Admin User (e.g. I0****6)
Site Minder Affliate Name: SAP Business Network Buyer Account Id (e.g. ANxxxxxxxxxxx-T)
Get Assertion Service URL: https://<SAP IAS tenant id>.accounts.ondemand.com/saml2/idp/sso?sp=<SAP Business Network Buyer Account Id>&index=1 (e.g. https://<SAP IAS tenant id>.accounts.ondemand.com/saml2/idp/sso?sp=ANxxxxxxxxxxx-T&index=1
Portal Query URL:
https://<SAP IAS tenant id>.accounts.ondemand.com/saml2/idp/sso?sp=<SAP Business Network Buyer Account Id>&index=1 (e.g. https://<SAP IAS tenant id>.accounts.ondemand.com/saml2/idp/sso?sp=ANxxxxxxxxxxx-T&index=1
Portal Login URL:
https://<SAP IAS tenant id>.accounts.ondemand.com/saml2/idp/sso?sp=<SAP Business Network Buyer Account Id>&index=1 (e.g. https://<SAP IAS tenant id>.accounts.ondemand.com/saml2/idp/sso?sp=ANxxxxxxxxxxx-T&index=1
Disable Manual Logon to AN: Disable SAP Business Network Login
Certificate Store for Site Minder SSL: *.crt certificate extracted from SAP IAS Metadata File

Once the instructions in opened case are executed, you have successfully configured the Single Sign-On (SSO) between SAP Business Network as Service Provider (SP) and SAP IAS as Identity Provider (IdP)!

See as well: