Over a million developers have joined DZone.

SAML Single Sign-On With JBoss Wildfly and PicketLink

To enable SAML Single Sign-On in Wildfly, you also need to enable SSL for the inbound connection / call back when the users browser sends their token supplied by the Identity Provider to avoid man in the middle attacks. Read on for more information.

· Performance Zone

Evolve your approach to Application Performance Monitoring by adopting five best practices that are outlined and explored in this e-book, brought to you in partnership with BMC.

For those of you who didn’t read my article about "Single Sign-On Made Easy: SAML With Tomcat and PicketLink" I will include the sequence diagram for SAML Single Sign-On here as well. For a detailed explanation of the diagram see my previous article.

Image title

To enable SAML Single Sign-On in Wildfly, you also need to enable SSL for the inbound connection / call back when the users browser sends their token supplied by the Identity Provider to avoid man in the middle attacks.

Commands for setting up SSL on JBoss (wildfly_ssl.cli)

create the script below and execute it with this command ”’ $JBOSS_HOME/bin/jboss-cli.sh –connect –file=wildfly_ssl.cli ”’

# Batch script to add and configure the quickstart-domain security domain in the JBoss server

# Start batching commands

# Add and configure the security domain, then add the PicketLink SAML2LoginModule. Which wil be used to extract user's information from the SAML Assertion and authenticate the user.
/core-service=management/security-realm=SSLRealm/server-identity=ssl:add(keystore-path=ssl-keystore.jks, keystore-relative-to=jboss.server.config.dir,keystore-password=changeit, alias=myhostname.local, key-password=changeit)

# Run the batch commands

# Reload the server configuration

/subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=SSLRealm)


It isn’t necessary to install PicketLink libraries on JBOSS because they are preinstalled.
Custom handlers may need to be installed depending on the configuration of the identity provider.

For one identity provider, I had to implement a handler for splitting a list of roles because they were stored in a single assertion attribute. In another case it was necessary to retrieve the the username from an assertion attribute and then change the user principal to reflect this name.

Web Application / Web Archive Structure

Here, our web app config will end up with the following structure:


Changes to the web.xml

You must define the role names used in LDAP within the web.xml like this:

    <description>App Users</description>

These roles will then need to be specified within the SecurityConstraints within the web.xml as well, like this:

        <web-resource-name>User Space</web-resource-name>

However, do not remove the login-config section because unlike in Tomcat here it is required even if never used.


Add picketlink.xml to the WEB-INF Folder

<?xml version="1.0" encoding="UTF-8"?>
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1">
  <PicketLinkSP xmlns="urn:picketlink:identity-federation:config:2.1" BindingType="POST">
  <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1">
    <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler" />
    <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" />
    <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler">
      <Option Key="ROLE_KEY" Value="http://schemas.microsoft.com/ws/2008/06/identity/claims/role"/>
    <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" />

Valves and Realms

Unlike Tomcat, here a valve is not required and, apart from the SSLRealm we configured earlier, there isn’t any need for a specific realm for SAML

JBoss Does Require a jboss-web.xml in the WEB-INF Folder

In this file is specified the Security Domain for the web app, the one configured previously in the cli file. We also define the context root of the web app which should match the prefix in the picketlink file when referring to the ServiceURL e.g. if the context is myapp the service URL is prefixed with “${myapp.url::”



In the META-INF folder add a file called jboss-deployment-structure.xml. This file should contain the module dependencies of the web app. In this case, we have added org.picketlink as a dependency.

<?xml version="1.0" encoding="UTF-8"?>


      <module name="org.picketlink"/>




Now we should add a service definition to the war, telling it to use the SPServletExtension. You do this by creating a file called io.undertow.servlet.ServletExtension in the folder WEB-INF/classes/META-INF/services/

The file should contain the following class name:



Useful command for checking out the log files which you use from the JBoss command line interface $JBOSS_HOME/bin/jboss-cli.sh –connect:


Learn tips and best practices for optimizing your capacity management strategy with the Market Guide for Capacity Management, brought to you in partnership with BMC.

saml ,wildfly ,single sign on ,sso ,picketlink

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}