Blueprint
How to connect Responsiv Unity or IBM BPM to Microsoft Azure
This blueprint is a step-by-step guide to configuring a Security Assertion Markup Language (SAML) based Single Sign-On (SSO) arrangement for accessing a Unity Process Node running the IBM Business process Management (IBM BPM) server on an IBM WebSphere Application Server v8.5 (IBM WAS).
Staff efficiency in enhanced, and security is improved when you deliver single-sign-on (SSO) for IBM BPM using Azure Security.
This blueprint assumes that you have a basic understanding of internet security and the concepts of single sign on.
Problem Description and Scope
SAML is an XML-based open standard that enables Identity providers (IdPs) to pass identity data to Service providers (SPs), in this case IBM BPM in a Responsiv Unity Process module. It can be used as the basis for implementing single sign-on (SSO) across multiple enterprise applications.
One Responsiv customer is using this blueprint to open their systems to their staff and partners – allowing business automation to span multiple companies.
In this article we will look at the setting up of a SAML SSO implementation to access the IBM BPM Process Portal user interface, which is running on a Responsiv Unity Process node. In SAML terms this will be the Service Provider.
The product that is performing the SAML Identity provider (IdP) role here is IBM Security Access Manager (ISAM). In other Enterprise Integration scenarios this role could be performed by Microsoft Azure AD or another identity management platform.
I loaded the certificate from the WebSphere server as a signer certificate into the pdsrv certificate database (used by WebSeal reverse proxies). I then followed the steps below from chapter 6:
- Upload mapping rules (javascript files)
- Create the federation (under the Secure Federation application of ISAM – accessed in the LMI management Interface). Details were entered per the below snippets in order to establish the federation.
- Export the details of this SAML federation to an xml file for import to the Service Provider.
The resulting Federation details:
The Federation details were exported to generate the federation_metadata XML file. This is imported later into the Service Provider (SP) (i.e., imported into WAS).
Service Provider Configuration (WAS)
Working through the relevant section of the IBM WAS documentation on the IBM Knowledge Centre (KC):
Firstly, create a new Enterprise Application to install the WebsphereSamlSP.ear file (find in the installable apps folder at the WAS home location – detailed below for both Unity versions).
- WAS Home on Unity 4 Process Node: /opt/ibm/BPM/v8.5
- WAS Home on Unity 5 Process Node: /responsiv/modules/3RDv5.0/BAW/install/BPM
This SAML application installation can be done using the WebSphere administrative console as shown below.
Take the default options:
Click Finish.
Save to the master configuration when prompted.
See it listed in the applications list and start it (using the select & submit actions):
Enabling the Trust Association Interceptor (TAI). Navigate through Global security > Web and SIP security > Trust Association to reach the menu shown below.
Setting the interceptor details:
For the acsUrl (ACS = Assertion consumer service) set the value to https://<server>.<domain>:9443/samlsps/ProcessPortal
Updating custom properties for name com.ibm.websphere.security.DeferTAItoSSO.
Possible VALUE BEFORE:
com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl
VALUE AFTER:
com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor
Also setup for name com.ibm.websphere.security.InvokeTAIbeforeSSO.
Value to be: com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor
Restart the WebSphere deployment manager.
Also check synchronisation across nodes:
Defining the ISAM Identity Provider (IdP) to the BPM Service Partner (SP)
The following step, carried out on the WAS SP, was taken from the below ISAM documentation link:
Execute the following commands on the linux server hosting the WAS deployment manager. This Imports the federation_metadata.xml file previously generated from the Federations screen on ISAM.
Then add the certificate from the ISAM (IdP) reverse proxy into the WebSphere Cell default trust store.
Check result in list of Signer certificates.
Add idp realms inbound trust (ALL):
Export Service Provider details
Run the below command on the WAS server to extract the SP definition for Importing into the IdP.
Identity Provider – Partner Setup (ISAM)
Ready to import SP federation xml into the IdP (ISAM).
Take defaults for following screens:
Result:
Note: It was also necessary to create a dummy self-signed personal certificate in the pdsrv certificate database on behalf of the WAS server name. This Is used In the SP partner configuration on ISAM – as seen above in the two key identifier fields.
The next step is to add a federation to the Reverse Proxy as shown below:
I chose below but cookbook has unchecked for reuse:
Next carry out instructions from chapter 8.1.2 – environment specific configuration. This included adding a new stanza at the end of the RP configuration file as below:
[junction:/isam]
reset-cookies-list = *ac.uuid,*JSESSIONID
In addition, I added the line highlighted below in the [TAM_CRED_ATTRS_SVC] stanza:
eperson = azn_cred_registry_id
[TAM_CRED_ATTRS_SVC:eperson]
emailAddress = mail
firstName = cn
lastName = sn
After this, apply the changes and restart the reverse proxy.
Configuring Access Control Lists on the ISAM IdP
I worked through the ACL commands per page 305 of the cookbook. These are shown below:
How to check the WAS Service Provider configuration
Reviewing https://www.ibm.com/support/pages/node/277989
And https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/twbs_displaysamlidp.html to show the Idp information:
Initiating a Web SSO Authentication from the IdP – URL Format
Here is the formation of a URL for testing a Federation (from page 103).
Format:
An IdP initiated SAML flow which uses HTTP POST binding can be triggered using
https://<IdP reverse proxy:port>/<junction name>/sps/<identity provider federation name>/saml20/logininitial?RequestBinding=HTTPPost&PartnerId=https://<SP reverse proxy:port/<junction name>/sps/<service provider federation name>/saml20&NameIdFormat=Email&Target=https://<TargetURL>
Web SSO Authentication Flow Steps – IdP Initiated
The steps for the happy path use case of a successful authentication flow go as follows:
- The user starts the process by following a link to a URL at the IdP
- The user authenticates with the IdP
- A SAML response Is created and sent by an HTTP Post redirect to an assertion consumer service In the Service Provider (SP). This response Is signed by the IdP
- The SAML TAI consumes the SAML response and logs In the user. Various security tokens are created In WAS Including an SSOToken. From this SSOToken a cookie Is created
- The request Is dispatched to the assertion consumer service (part of the SAML TAI). This redirects the user to the landing page for the target BPM application (I.e. the Process Portal)
Ian is an experienced technical project manager and systems administrator.
