SSO Plugin
Case study: Integrating with Ping
Federate
J System Solutions
http://www.javasystemsolutions.com
Introduction ... 3
Ping Federate Service Provider configuration ... 4
Assertion Consumer Service URLs ... 6
Signature Verification Certificate ... 7
Importing the key into Ping Federate ... 7
Digital Signature Settings... 8
Importing the certificate into a keystore ... 8
Configuring SSO Plugin ... 10
Introduction
This study provides in-depth steps for integrating the JSS SSO Plugin with Ping Federate. It does not aim to discuss:
Ping Federate configuration in great detail as this should be known to the Ping Federate administrator, and there are plenty of tutorials online.
SSL configuration of the Java web server running SSO Plugin, and there are plenty of tutorials online. Whilst SSL is not required for a PF integration, it is recommended for production deployments.
The integration will:
involve both message signing and verification within SSO Plugin and Ping Federate, providing security in both directions. The Ping Federate instance is SSL enabled, as it is out of the box, and the SSO Plugin instance is not.
use the SAML POST profile, which is the most common solution for SAML integrations, because SAML Redirect can be unreliable, and SAML Artifacts are very complicated.
Ping Federate Service Provider configuration
The Ping Federate administrator has created a Service Provider within PF for SSO Plugin.
The points of interest are as follows:
1. The Assertion Consumer Service URL (image 3). 2. The Single Logout (SLO) Service URL (image 3).
3. The Digital Signature Settings and Signature Verification Certificate (image 4). If SAML Artifacts are required, the SSO Plugin resolver URL can be noted under Artifact Resolver Locations (image 3). SAML Artifacts are not covered in this study.
Assertion Consumer Service URLs
These are defined as the endpoints to which a user can authenticate (on SSO Plugin) and the Test SSO URL has been configured. The URL is pointing to an SSO Plugin deployed to a Tomcat instance running on localhost (port 8080).
There are two ways you can approach this configuration.
1. Define each end point a user could access, ie on BMC Mid Tier, http://host:port/arsys/home, http://host:port/arsys/forms (etc).
Organisations will have different policies and ways of achieving this goal. The easiest way is to use the universal access point however this requires an additional configuration step within SSO Plugin: ticking the "Use single Assertion Consumer URL" checkbox when setting up the SAML configuration.
For the purposes of this study, the first approach is demonstrated, ie defining specific URLs.
Signature Verification Certificate
For SSO Plugin to sign SAML requests that are verified by PF, public and private keys need to be generated.
Using the keytool program, found in the Java Runtime Environment bin directory, run the following at the command line, which creates a new keystore (a collection of keys/certificates, each keyed with an 'alias') and populates it with a private key using an alias called sp:
keytool -genkeypair -keyalg rsa -sigalg SHA256withRSA -keysize 2048 -keystore samltestkeystore.jks -alias sp
This is enough for SSO Plugin to sign requests, but PF requires the public key to verify the requests. The following exports the public key:
keytool keystore samltestkeystore.jks storepass password exportcert -alias sp -file ~/tmp/ssoplugin.cer
Importing the key into Ping Federate
Then return to the Service Provider overview, select Signature Verification Certificate and select the SSO Plugin key that has been imported.
Digital Signature Settings
This defines the certificates used to sign the SAML responses sent from PF to SSO Plugin. For SSO Plugin to verify the SAML sent by PF, the certificate needs to be exported from PF and stored in a file.
To do this, click Digital Signatures, Manage Certificates, Export on the certificate selected for the SP, and export the 'certificate only'. We assume this is stored in a file called ping.crt.
Importing the certificate into a keystore
For SSO Plugin to use the certificate exported from Ping, we must import it into the keystore created earlier. To do this, run the keytool command, importing the
certificate using an alias called ping:
keytool -keystore samltestkeystore.jks -storepass password -import -alias ping -file ping.crt
Valid from: Wed Jun 29 14:18:17 BST 2011 until: Fri Jun 05 14:18:17 BST 2111 Certificate fingerprints: MD5: 8D:4E:8C:8F:69:46:E4:83:82:09:C2:E4:6E:4A:85:2A SHA1: 69:7D:39:A0:BF:D5:90:BF:79:11:5E:F3:1C:55:EA:F6:5F:39:F4:E5 SHA256: D5:DF:DE:E9:BF:D9:C1:81:87:57:DC:7C:14:34:81:5D:22:B2:01:F5:FC:F6:49:24:7C: A7:AE:16:80:9C:77:62
Signature algorithm name: SHA1withRSA Version: 3
Configuring SSO Plugin
The following image shows the SSO Plugin configuration for the PF integration. It assumes that the universal URL has not been configured in the Assertion Consumer URLs within the SP configuration, and hence the "Use single Assertion Consumer URL" checkbox is not selected.
Testing the integration
Once SSO Plugin has been configured and no errors are reported when the 'Set configuration' button is pressed, the Test SSO link will create a SAML request, sign it using the private key configured when the keystore was created, and the browser will send the message to PF.
If PF is configured incorrectly, it does not always report the errors in a meaningful fashion to the browser. Typically, it sends the browser back to the requested page (ie the Test SSO page) and hence SSO Plugin creates a new request which gets sent to PF. If this loop occurs three times, SSO Plugin displays an error page to avoid a continuous loop. PF will have written error messages to the PF logs and these should be examined.
If PF is configured correctly, and in our case we're using the default PF IDP, it will display a login page:
This completes the integration. The next steps are to implement SSL on the Java web server running SSO Plugin and to implement either a universal URL for the Assertion Consumer URL or to specify all the URLs in the target application (ie BMC Mid Tier, HP Web Tier, etc) that a user can access through PF.
