Cluster. | Description | Steps |
1. | Couple your BTP subaccount and your SAP IAS tenant. | 1 - 6 |
2. | Configure applications (relying party) in Azure AD and Okta IDP based on OpenID Connect and SAP IAS as the callback URI. | 7 - 25 |
3. | Configure application in Okta with SAML Trust to SAP IAS. | 26 - 33 |
4. | Onboard the above Corporate Identity Provider configurations into SAP IAS. | 34 - 46 |
5 | Switch the responsibilities - configure IAS as the proxy Identity Provider and SAP BTP as the Service Provider. | 47 - 52 |
6. | Test the setup. | 53 - 60 |
Step | Description | Screenshot |
1. | Head to your 'tenant settings' section within your SAP Cloud Identity Service tenant (this will be referred to as SAP IAS in this blog post) and review the 'Global Account' that has been assigned. | |
2. | Now, head to your BTP Cockpit and verify that the Global Account here matches with that of the IAS tenant's. If not,you may have to get in touch with Product Support that helped with your provisioning request, and have this sorted out. You will not be able to link the two entities and proceed further if you do not meet this pre-requisite! | |
3. | Click on the 'Enable Trust' button from the Trust Configuration section. Note: we do not click on import SAML Metadata! | |
4. | If all prerequisites were met, you will be presented with a dialog that identifies your IAS tenant. Go through the wizard and finish the steps. | |
5. | Once created, notice that the 'protocol' will be set to OpenID Connect. | |
6. | As a final step, head back to the 'Applications' section in your IAS tenant and you should be able to review that the system automatically created an Application with the needed configurations, on your behalf. Change the 'Subject Name Identifier' to 'email'. We will come back to this 'Application' after completing the other steps in the flow. |
Step | Description | Screenshot |
7. | Login to the Azure Portal (e.g. with your Microsoft 365 E5 developer subscription’s admin account) and select Azure Active Directory from the Azure Services. Select App registriations from the left-hand navigation and click on New registration. | |
8. | Enter “APIBusinessHubEnterprise” for the Name of the new application registration. Select “Web” from the dropdown list in the Redirect URI section. Enter your IAS tenant’s redirect URI in the Redirect URI section’s text field: https://<IAS tenant name>.accounts.ondemand.com/oauth2/callback. Replace <IAS tenant name> with your tenant’s name. Click Register. | |
9. | Keep a note of the client identifier (Application ID). We will need it later during the corporate Identity Provider registration step in SAP IAS. | |
10. | Go to 'Certificate and Secrets' section and generate a new client secret. | |
11. | Make a note of the generated client secret. Be mindful that this value will not be displayed again. | |
12. | Go to the 'Token configuration' section and click on 'Add optional claim'. This step is needed because the BTP Application (API Business Hub Enterprise) needs these additional claim attributes mandatorily in order to complete the user registration step (not covered in this blog post). More on this step later as we get to 'Test'. | |
13. | Select the token type as 'ID'. (i.e. the claim will be available within id_token). Check 'family_name' and 'given_name' as the claim attributes to add. | |
14. | Enable any additional scopes and permissions, as sought. | |
15. | Optionally, you may add group claims. This will enable XSUAA to leverage the values of the group claims and map them into 'RoleCollections'. |
Step | Description | Screenshot |
16. | Login to your Okta account, if you have one. If not, the Okta developer account is a great place to start. Go to the Applications tab from your dashboard and 'Create a new App Integration'. | |
17. | Select 'OIDC - OpenID Connect' for the Sign-In method and select 'Web Application' for the Application type. | |
18. | You can proceed by selecting most of the presented defaults here. Enter your IAS tenant’s redirect URI in the Redirect URI section’s text field: https://<IAS tenant name>.accounts.ondemand.com/oauth2/callback. Replace <IAS tenant name> with your actual tenant’s name. | |
19. | To keep things simple, let us allow everyone in the organization to sign into the app. You can always change this later. | |
20. | Make a note of the client ID and client secret. We will use this later. | |
21. | Next, we will create a few users in this organization. Go to Directory -> People -> Add person. Make sure you assign the 'First Name', 'Last Name' and 'Email' attributes. I will be adding my @Sisn.com user here to keep things simple. | |
22. | Similar to step 12, we need to enable the Authorization Server to dispense the user's first name and last name as JWT Claims. To do so, go to the 'API' tab within the Security group on the left, and go to the 'Default' authorization server. | |
23. | Go to the Claims tab and click 'Add Claim'. | |
24. | Call the claim as 'last_name', we need to add this to the ID Token claim (SAP IAS expects so). The value this attribute maps to is 'user.LastName'. | |
25. | Repeat the same step as above. We will call this claim 'first_name' and enter 'user.firstName' as the value this maps to. |
Step | Description | Screenshot |
26. | Create a new app integration and select 'SAML 2.0' for the Sign-In method. | |
27. | Give the application a meaningful name and proceed. | |
28. | At this juncture, we will need the SAML URLs from the IAS tenant. Let us jump back to our IAS tenant to do so. Go to Home -> Tenant Settings -> SAML 2.0 Configuration. | |
29. | Make a note of the Identity Provider Name and the Assertion Consumer Service (ACS) Endpoint URL. We will need this in the steps that follow. | |
30. | Head back to Okta, get into SAML configuration tab. Enter 'https://<IAS tenant name>.accounts.ondemand.com/saml2/idp/acs/<IAS tenant name>.accounts.ondemand.com'. This is basically the value of the ACS URL we copied from the step above. Check 'Use this for Recipient URL and Destination URL'. Enter 'https://<IAS tenant name>.accounts.ondemand.com' for the Audience URI (the 'Name' property that we copied in the step above, EmailAddress for the Name ID format. Enter mail, first_name, and last_name as additional SAML attributes with the same mapped values as in step 25. | |
31. | Let us add 'Groups' with Group Attributes and .* as the regex pattern. Click on the Preview button to have the actual values populated. | |
32. | Verify that the attributes are populated as you would expect. | |
33. | We will need the SAML Metadata URL later during the IAS configuration (in order to set up mutual Trust between Okta and IAS). Go to the Sign On section and copy the Metadata URL. |
Step | Description | Screenshot |
34. | Go to 'Corporate Identity Providers' from the 'Identity Providers' tab. | |
35. | Click 'Create', let's call this Azure AD, and select 'OpenID Connect compliant' for the type. | |
36. | Enter your Azure AD tenant’s OIDC Discovery URL (https://login.microsoftonline.com/<AAD tenant ID>/v2.0) Click Load. Many required fields will be pre-filled from the Azure AD tenant’s OIDC metadata. | |
37. | Enter the 'Client ID' and 'Client Secret' with the values we retrieved in Steps 9 & 11. Within the 'Scopes' section, click on Add and enter 'email' and 'profile'. We need these scopes to fetch the user's first name, last name claim values from the id_token. Click Validate. | |
38. | This step will have you authenticate to Azure Active Directory. Sign in with the user who has access to the Application we created in step 9. | |
39. | Upon successful validation, verify that the id_token indeed presents the family_name, given_name and groups claims. If this is not the case, inspect your configurations. | |
40. | Repeat step 35, this time to onboard Okta as the corporate identity provider. Within the OpenID Connection configuration section, enter 'https://<okta account>.okta.com/oauth2/default/.well-known/openid-configuration' as the discovery URL and Load the rest of the endpoints based on this. Enter the client credentials from step 20, email and profile scopes and 'Validate'. | |
41. | Similar to step 39, inspect the id_token and verify that the first_name, last_name and Groups are populated as expected. | |
42. | Next, head over to 'Subject Name Identifier' settings in the main section and select 'Email'. Within the Single Sign-On section, toggle the 'Forward all SSO request to Corporate IDP' to ON. | |
43. | Next, we will process the additional attributes coming from the Identity Provider. Go to the Identity Provider settings that correspond to your 'Okta' IDP, go to Enrich Token Claims and map $(last_name) and $(first_name) to family_name and given_name respectively. Note that this step is not required for the Azure AD IDP, as the names of the claim attributes already were set to the ones that IAS understands (i.e. family_name and given_name) | |
44. | Go to the Identity Federation section and Turn On the User Store and User Access toggle switches. What this means is that the assertion is being massaged by IAS before it can be forwarded to downstream Applications. You can switch these OFF at a later point to inspect this behavior too. | |
45. | Repeat step 34, this time we will register a corporate Identity Provider to register the SAML IDP we created in Step 26. Let's call this Identity Provider as 'okta-developer-account-saml' and set the identity provider type as 'SAML 2.0 compliant'. | |
46. | In the SAML 2.0 configuration tab, load the metadata with the URL we copied in step 33. Make sure that 'Single Sign On' forward all requests to corporate IDP is turned On. This completes the setup of the 'Corporate Identity Providers'. | |
47. | In the next few steps, we will set up the configurations needed for the handshake between IAS and BTP (XSUAA). To do this, go to 'Application and Resources' in the main IAS Tab and go to the Application that represents your BTP Sub Account. (see step 6) | |
48. | Go to the 'Assertion Attributes' section. Here we will create a mapping between the assertion attributes that were processed from the corporate identity provider and the user attributes that the application will propagate to BTP (user attributes). Enter all the values of the claims that we have dealt with so far ( e.g. first_name, last_name that came in from Okta etc.) | |
49. | Now, to the most important step. We need to configure conditional authentication that will determine the order and logic to forward user requests to the right identity Provider. The screenshot depicts the settings that work for me. You are free to define your criteria. For example - users from the *.sap.com domain will be forwarded to 'okta-developer-account' identity provider, provided the user does not have the 'APIAdmnistrator' user group assignment, else it will use IAS as the default IDP. | |
50. | Lastly, we need to enable SAML on this Application as well so that SAML-based federation can be leveraged. Go to 'Configure SAML 2.0 Requests to Corporate Identity Providers' and select 'Service Provider Authentication Context'. | |
51. | Here is an example of User Groups management in SAP IAS. Go to 'Users and Authorizations' from the main tab and go to 'User Groups'. As an example, I've created a group called 'Supplier' and have a user assigned. A similar assignment for a group named 'APIAdministrators' exists, as well. You are free to make your own group assignments. | |
52. | Our final step is to review the Trust Configuration setting in SAP BTP Cockpit and ensure that this IAS Application is accurately marked as the Trusted IDP that the Application will use to log users into. It is ok to have multiple IDPs active here, I will demonstrate having just one active and focus my attention on the API Business Hub Enterprise application (within Integration Suite) |
Step | Description | Screenshot |
53. | Enter the 'API Business Hub Enterprise' URL (in this case: https://<account identifier>.apibhubenterprise. cfapps.us10.hana.ondemand.com/). I am not showing the steps to log in to Integration Suite to keep the narrative simple. You will notice here that you are forwarded to your IAS Application. I'm signing in with my *.sap.com user. | |
54. | Based on the conditional authentication set (step 49 ), the system has determined that I need to be challenged to Okta. I am prompted to enter my Okta username and password. | |
55. | Our Okta OIDC App (step ) attempts to sign us in. | |
56. | Lo and behold! After the handshake successfully completes, I am taken to my ABHE home page, where I can see the published APIs and Products. Note that I was already registered as a user in ABHE. The user registration step itself is not a subject described in this blog. | |
57. | Let us look behind the scenes to see what exactly is happening here. Head back to your IAS tenant and within the 'Monitoring & Reporting' tab, go to 'Troubleshooting Logs'. | |
58. | Apply the selected filter, and search for the term 'jwt'. Of the many entries that show up, look for the ones that have the keywords 'recieveJwtToken' and 'issueJwtToken'. | |
59. | Take a closer look at each of these log entries, the 'receiveJwtToken' is basically the token IAS receives from the Identity Provider. Note the first_name and last_name attributes here with their corresponding values. | |
60. | The 'issueJwtToken' is basically the token that IAS issues to BTP, you will notice here the given_name and family_name attributes being relayed. | |
61. | I will not cover the screenshots here, but you can try logging in with your Azure AD user, with SAML identity provider and you will notice that it works seamlessly. Go back to the 'Identity Federation' setting in the 'Corporate Identity Provider', and you can switch off 'Use Identity Authentication user store', leave a comment in the blog to let me know if you see any different behavior. |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
29 | |
13 | |
12 | |
10 | |
10 | |
9 | |
9 | |
7 | |
7 | |
6 |