This guide outlines the key configuration steps that had to be done in order to get an application to work with PingFederate (www.pingidentity.com). During this process, the IdP was mostly a black box to me. The developer on the IdP helped to configure, but I had no knowledge of how to configure the IdP side. So, this article will strictly cover the SP aspects.
The key goals of this initial project were simple:
- PingFederate will act as the identity provider (IdP) to authenticate the user.
- Attributes will be returned to the SP to parse and utilize within the application.
For this project, we determined that JBoss 5.1 would be our application server and we would utilize Java 1.6.
Download the distribution
The version that ultimately worked for us is a 2.0 build, dated Mar 16, 2011. This build contains bug fixes that enabled the attriubtes to be parsed and added to the user session. The following link contains the v2 builds:.
Deploy the supporting libraries
Following the guidance of another article, I took the following JARs and deployed to $JBoss/server/default/lib.
The only other setup task was to take the bean deployment XML, picketlink-sp-jboss-beans.xml, and place it in the $JBoss/server/default/deploy folder.
For initial testing, I deployed the sample IdP web application, idp.war. This is a great way to start - it makes sure that everything works as it should initially.
Setting up the web application
To begin, I took one of the web applications that comes with the distribution, employee-post.war. The 'post' portion identifies that we're using POST authentication. Predictably, I unzipped the distribution, renamed it to something else that identifies our project and deployed to $JBoss/server/default/deploy.
Since we're running on JBoss 5.1, we made sure that the following line was in WEB-INF/context.xml:
To enable authentication, the following lines must be in WEB-INF/jboss-web.xml.
Note: 'sp' is deployed by picketlink-sp-jboss-beans.xml, referenced above.
For our use cases, we determined (through much trial and error) the following handlers were necessary.
This configuration option is unchanged from the default.
For authentication, it was necessary to disable role picking (we were not utilizing this), and to specify the nameid-format as 'unspecified'. These 2 configuration options were absolutely essential for this solution to work. Note that your specific solution may not require these, just know that any of the standard nameid-formats will work.
<Option Key="DISABLE_ROLE_PICKING" Value="true"/>
<Option Key="NAMEID_FORMAT" Value="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
This handler takes the attributes that are returned from PingFederate and places them into the user's session. See the usage of this feature at the following link: https://issues.jboss.org/browse/PLFED-159
<Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AttributeHandler" />
Configuring this file was the initial hurdle. The most important aspect is to get the service URL correct. The configured information is passed to the IdP, but our implementation required us to tell our IdP counterparts this same information. Initially, a trailing slash was not configured for the service URL. The side effect was that the browser kept bouncing back and forth between IdP and SP sites since after authentication the SP was never receiving the information. So, below is what is required. I've obfuscated the domains and context.
<PicketLinkSP xmlns="urn:picketlink:identity-federation:config:1.0" ServerEnvironment="jboss">
Also, note that the ServerEnvironment is assigned the value 'jboss' since we're deploying to JBoss. The examples are set to 'tomcat', which may work, but I was instructed to make this change.
The configuration is straightforward in that there is no special code that needed to be written, and the correct options needed to be known. But, probably like most people, I came to this knowing next to nothing about SAML, just that it was necessary for our project. This provided our proof of concept so we could move forward confidently.
Special thanks goes to the community for providing tons of support and answering any and all questions, making numerous bug fixes/builds to make this a success.