In a recent customer proof-of-concept/prototype I integrated with my esteemed colleague Sergio O., OpenSSO and IBM DataPower for single sign-on. It appeared to be easier and quicker than I initially thought. Here's how it worked for us:
IBM DataPower can be configured in many different ways. In our case it is used a an XML firewall which exposes endpoints that asserting parties can post SAML assertions to (SAML 1.1 and SAML2). DataPower proceeds as follows :
1.) Receive SAML assertion (through HTTP-POST)
2.) Verify assertion signature
3.) Extract user name from the NameIdentifier (SAML1.1) or NameID (SAML2) field
4.) Issue appropriate LTPA token to user
IBM DataPower was also configured to POST SAML (1.1 and 2.0) to specific endpoints (relying parties, here FAM) upon initiation by user (e.g. click a link or button).
In order to achives bi-directional SSO based on SAML, we were faced with the following challenges:
DataPower needs to be configured so that it can validate the signature by FAM. FAM in turn needs to be configure with the asserting parties signature key (through metadata).
- User name mapping
The NameIdentifier (SAML1.1) and NameID (SAML2) tags had to match the Websphere username that DataPower issues an LTPA token for. This requires a custom NameIdentifier mapper for SAML1.1 that injects only the RDN attribute value rather than the user DN in the NameIdentifier tag. For SAML2 it had to be a custom IDP account mapper that does the same and sets the NameIDFormat to urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified.
- Craft DataPower Metadata
This is relativly easy from a template generated by famdadm. It is important to include the correct certificate though.
- Correct DataPower's Assertions
We had to correct some elements in the SAMLResponse sent by DataPower like the presence of the ResponseTo field of an unsolicited response. The debug logs (when log level set to message) really helped here (files libSAML and libSAML2).
Hopefully getting this in a more detailed paper soon.