Single Sign On to Open Connectors in SAP Integrati...

vinayak_adkoli · ‎11-06-2021

Background and Context:

Being able to connect to non-SAP systems via Open Connectors is an important part of SAP Integration Suite's proposition. In addition, customers have been using SAP Open Connectors as a standalone product within SAP BTP's Neo and multi-cloud environment as well.

This blog post will demonstrate the ability to log into the Open Connectors Design time web-UI with a single sign-on (SSO) experience that will authenticate to Microsoft Azure Active Directory (AD) Identity Provider.

It needs to be mentioned that while users can log into the BTP Cockpit (or for that matter to the Integration Suite launchpad) with single sign-on to say Azure AD or any other custom Identity Provider by virtue of the Trust configuration in the BTP Cockpit's Security section (and then subsequently assigning the required role collections, e.g. Integration_Provisioner / OpenConnectors_User to access the needed tiles on the launchpad), the ability to access the Open Connectors UI by authenticating to the external IDP needs an additional onboarding and authentication step.

You may refer to this blog for steps on authenticating to Open Connectors UI with users from SAP Identity and Authentication Service (SAP IAS). In this blog post, we achieve the same result by authenticating against Azure AD.

Additional blogs on Open Connectors capability in the SAP Integration Suite are covered in Simplify integration with non-SAP applications blog series.

Prerequisites:

An SAP Integration Suite (or even SAP Open Connectors) tenant (productive / trial) where Open Connectors capability has been activated.

Subscription to Azure Portal and Active Directory services

Procedure and Steps:

Step 1: log in to your Azure Portal and navigate to 'Azure Active Directory' service.

Step 2: Navigate into Manage 'Enterprise application' menu tab.

Step 3: Click on 'New application'. This is where we will set up the Service Provider metadata credentials to establish the needed single sign-on.

Step 4: Click on 'Create your own application' button. Note that though Azure will list a number of SAP service provider templates in the 'SAP' gallery, the service provider for Open Connectors is not templatized yet.

Step 5: Name your application. As a general practice, you may want to add the BTP account Id as a suffix for easy identification.

Step 6: Click on 'Single sign-on' menu item.

Step 7: select 'SAML' as the SSO method

Step 8: Here I am demonstrating a simple approach where the user email ID attribute will be assigned as the unique user identifier in the SAML assertion. It is up to your organization's policy on how you would like to go about defining this step. It is important to note that the format of this unique user identifier will be carried forward as we later configure the user/member on the Open Connectors side.
Click on 'Edit' to set this.

Step 9: By default, the user identifier is set to UPN (user principal name). Click on the three dots to change this.

Step 10: Set the Source attribute to 'user.mail', save your changes and head back to the main configuration page.

Step 11: Azure would have generated an IDP metadata URL at this point. We will need details from this metadata for subsequent steps. Copy the Metadata Url to the clipboard and open this on a new browser tab.

Step 12: Make a note of the 'entityID' attribute and the X509Certificate attribute from the keyDescriptor node. Here is an important point to note - As can be seen in the screenshot below, there are multiple nodes of the KeyDescriptor element which end up creating a problem in subsequent steps. It is a good idea to refresh the configuration page a few times to check if there is only one KeyDescriptor element (only then would our test succeed). But unfortunately, if this doesn't change, we may have to come back to this step later.

Step 13: Make a note of the HTTP-Redirect binding value from the Location attribute.

Step 14: Now, let's head back to the Open Connector UI -> Security tab -> Identity -> Application Identity Provider section and click on 'Add Trusted Identity Provider'.

Step 15: Fill in the details on this form with the values copied from steps 12 & 13. Select 'emailAddress' as the Name ID Format and enter the x.509 certificate details.

Step 16: Select RSA-SHA1 as the Signature Algorithm, set the Strict Mode to 'true', and Save your changes.

Step 17: Once created, download the Trust settings.

Step 18: Head back to Azure AD and within the Application created in the previous step, upload the Trust settings from the previous step by clicking on Upload metadata file.

Step 19: Once you save your changes, review the entries in the Basic SAML Configuration section. Refresh the page.

Step 20: Navigate to the 'User and groups' tab in the main Manage section, click on Add user/group button and onboard the users you need from the Active directory store into this Application.

Step 21: You may either Test single sign-on from the Azure page or try logging into Open Connectors UI page in a new browser window.
Useful Tip: Do not close your existing browser window of the Open Connectors page where you are already logged in. This way you can continue with that existing session if the new session is corrupted owing to failed authentication, which may stop you entirely from logging in.

Step 22: There is a likelihood that your logon may fail with an error message as depicted in the screenshot below. This goes back to the point we discussed in Step 12 where the certificate settings in the federation metadata Url were possibly inaccurate.

Step 23: Go back to the federation metadata Url (from step 11), refresh the page and hope that the x509 certificate is reflected correctly in the KeyInfo section (no duplicates of the KeyDescriptor node)

Step 24: Frustratingly, you may have to delete the Identity Provider settings from the Open Connectors security page, re-create and re-import it back again till such time the certificate value shows up correctly. (it's a bit of a hit and miss)

Step 25: Note that each time you delete the metadata and re-import it, the SAML metadata identifier increments, as highlighted.

Step 26: If you are testing by directly opening the Open Connectors UI in a new window and you encounter a new error that says that the authorized user is not found congratulations, you are one step closer!

Step 27: Head to the 'Members' tab on the Security settings page and make sure you onboard a new member with the user identifier that you would have previously configured in step 10, i.e. the User's email address in my case.

Step 28: Finally, success! You will be able to log in to the UI by authenticating the user against the configured Azure AD application.

Handy Tip: In case you are having issues with logging in to the UI, you may use a network tracing tool like SAML Tracer with Firefox browser to inspect the user attributes in the SAML token that are being presented by Azure AD to the application and verify if this is what you expect.

Manjunath · ‎11-06-2021

Thanks vinayak.adkoli for the blog. I understand this blog helps us at design time SSO, does it works same at run time as well.

vinayak_adkoli · ‎11-07-2021

Manjunath, yes that is correct.

For the runtime, one would have to anyway create an instance of the Connector (and authenticate to that provider system based on what it accepts - typically OAuth 2.0 standards). Open Connectors would then generate a unique authorization token for this connection

svenhuberti · ‎11-11-2021

Thanks Vinay, very good structured blog!

As Manjunath was saying, this only works for design-time. Is it planned, or even possible as of today, to use the current user's credentials (say from an app) to invoke open connector instance API, instead of using a technical user?

Thanks!

vinayak_adkoli · ‎11-19-2021

Hi svenhuberti ,

If you think about it, this (user's credentials) is exactly what is happening today. As an example, when you create a connector for say Microsoft Graph, OneDrive etc. the app that one would have to register on Microsoft Active Directory can be set for 'Delegated User' (i.e. the client application - OCN would have the permission to act on behalf of the user who is authenticated during the OAuth registration step), which means when user invokes the OCN API to get say my Calendar items, the App would retrieve the calendar items for the user who authenticated during the instance creation step.

But there could also be use cases while setting up the providers where the user context is not needed or does not make sense. for example to get the list of all files from Sharepoint, it is also possible to set up 'Application' permissions which would behave in a service-service communication context.

former_member226 · ‎11-27-2021

Nice blog vinayak.adkoli .

As mentioned in steps 12,23,24, I faced exactly the same issue and even after multiple refreshes it was not going off. But then I found the "Download" link under "Federation Metadata XML" in the same UI (SAML-based Sign-on) as shown. This was always giving a single signing certificate value that can be easily copied over to Open Connectors. hence no need to refresh again and again, just simply download this to extract the information like EntityID or signing certificate or SLO/SSO URL etc.

Azure Federation XML Metadata