Background and Context
By default, all SAP Cloud Platform Accounts come connected to SAP ID Service at the Identity Provider. Identities of S-user accounts as well as SCN Accounts (P-users) are managed by the SAP ID Service. While this is a great starting point for customers and partners, it's obvious that they would eventually want to use Identity Providers that natively have been setup in their organization, for example, Azure Active Directory / Okta / etc. Many customers also use SAP's own Identity Authentication Service (IAS) as the Identity Provider directly or even use IAS as a proxy to their actual corporate user stores.
In this blog post, we will setup IAS as a custom Identity Provider in order to configure Roles to access the Integration Suite capabilities.
Settings on the Identity Provider
Configuring an IDP to supply identity to applications on a subaccount is basically a two-step process to setup a mutual Trust via an exchange of SAML metadata artifacts. As a first step, let us grab the SAML metadata from the Subaccount where we are hosted.
The 'Trust Configuration' section has a button to download the SAML Metadata. Click on this button and locally save the XML representation of the metadata file.
Now, head over to the Administration page of your IAS tenant to configure the artifact that we just downloaded. The 'Applications' section lets us configure different Application (identity) settings.
Let's call our Application 'Integration Suite App'.
The 3 important sections here that need to be configured are - a) Configurations to setup the SAML Service Provider (SAP Cloud Platform) b) Subject Name identifier and c) mapping of the Assertions that need to be made available into the Service Provider.
For the first part, upload the SAML metadata previously downloaded in the first step.
For the second part, specify that the email of the user ought to map to the mail attribute in the Assertion. This is important because by default XSUAA expects the email attribute as the subject identifier.
For the third part, add the user Attribute 'Groups' and assign it to the Assertion Attribute called 'Groups' (case-sensitive)
The next configuration on the IDP would be to leverage the concept of 'Groups' to pack into the SAML Assertion and not having to deal with individual user assignments during the Role management step on the Cloud Foundry. Such an approach is preferred by many IT organizations as it permits an easy onboarding and offboarding of users and permissions they carry just at a single place (i.e. the IDP itself)
In the User Management section, we onboard two users for demonstration purposes. This will be leveraged in a different blog article when we want to distinguish between Administrator and external developer permissions.
We head over to the User Groups section and here we see that there are 3 groups configured for our purpose: 'IntegrationDevelopers', 'APIManagementAdmins' and 'ApplicationDevelopers'
Note that our target user 'P000438' has been assigned to the APIManagementAdmins group.
Now we prepare for the second part of configuring the custom Identity Provider setup by downloading the SAML configurations that correspond to this instance of IAS.
Click on the 'Download Metadata File' button.
Settings on SAP Cloud Platform's Subaccount
Next, head over to the Cloud Foundry subaccount's Cockpit and click on the 'New Trust Configuration' button from the Trust Configuration section.
Import the SAML metadata file downloaded in the previous step. The other step to call our here would be that we explicitly enable the configuration for users to log into (SAML Service Provider settings). We've also enabled this for Shadow User creation, that would mean that user login details that are presented by the identity provider are automatically used by the UAA component to create 'shadow users' by default. At this juncture, we've enabled this step primarily as a means to do away with explicitly providing user email addresses for the UAA to grab.
we call the Trust configuration as 'isuite-idp'. Note that we've left both the Trust Configurations (SAP ID Service and our custom created) as Active.
We go back to the Subscriptions Tile and click on 'Go to Application'.
Since SAP ID Service was marked as 'Active', we need to explicitly tell the system that we intend to Sign in with the custom Identity Provider.
Let's log on by providing the user id and password credentials. The system (UAA) will pick up the corresponding email address from the authenticated session and create a shadow user.
But since we haven't yet associated the user yet with any Role settings, the application prompts us stating that it couldn't find the role it was looking for.
Let's head back to the Trust Configuration settings.
Let's go the 'Role Collection Mappings' section instead of attempting to do a per-user assignment.
Select the 'Integration_Provisioner' Role Collection and assign the value of the Groups attribute to 'APIManagementAdmins'. You will recall that is the custom Group we had created in the IAS tenant.
Now (in.a new session) let's invoke the Integration Suite Application.
For purposes of inspecting the SAML assertion that the Browser negotiates, we've enabled the SAML Tracer plugin. Here we clearly can establish that the Assertion presented by the Identity Provider to the Application populates the Group attribute in addition to other standard fields.
and finally, welcome to the Integration Suite launchpad!
Next steps
Now that we find ourselves in the Integration Suite's launchpad, follow along with the remaining parts of configuring the Integration Suite via the launchpad in the blog here. In some of the upcoming Blog articles, we will also explore using this setup to explore API access mechanism for the API Portal and Developer Portal.
- SAP Managed Tags:
3 Comments
