A Security Token Service (STS) is a Web service that issues security tokens according to the WS-Security protocol. It is a standard component of security network that enables actions like: authentication, identity validation or security token exchange.

Gazelle-STS has been developped for testing purpose only. It is able to distribute security assertions for different test cases : valid, expired, unknown service provider, etc.

It relies on Picketlink 2.7.0.Final. Gazelle-STS also requires to query Gazelle Security Suite (with PKI mode enabled) to validate security tokens.

Sources & binaries

Gazelle-STS is an open-source project under Apache License Version 2.0 ( Sources are available via Subversion at

The latest public packaged release can be downloaded from our Sonatype Nexus repository gazelle-sts releases (search for gazelle-sts-service-X.X.X.war).

STS Installation

If you are installing a Gazelle tool for the first time in your environment, make sure to read carefully the general considerations for JBoss7.

Jboss 7 configuration

  1. Edit to ${JBOSS_INSTALL_DIR}/standalone/configuration/standalone.xml

  2. Add in <subsystem><security-domains> the following lines

<security-domain name="idp" cache-type="default">
    <login-module code="UsersRoles" flag="required">
      <module-option name="usersProperties" value=""/>
      <module-option name="rolesProperties" value=""/>
<security-domain name="gazelle-sts" cache-type="default">
      <login-module code="net.ihe.gazelle.sts.login.STSLoginModule" flag="required"/>
<security-domain name="sp" cache-type="default">
    <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule" flag="required"/>


No database is required for Gazelle-STS


To deploy Gazelle STS :

  1. Paste the archive gazelle-sts-service.war in the JBoss deployment directory ${JBOSS7\_HOME}/standalone/deployments/

  2. Display JBoss server logs, start JBoss and wait for war deployment.

  3. The application can be browsed at http://localhost:8080/gazelle-sts?wsdl.
    Port could also be different whether you have modified the JBoss configuration.


By default, the project is configured for working in environment. The keystore used to sign assertions must be located at /opt/sts/keystore.jks, the privateKeyEntry must have the alias tomcat, and the certificate validator webservice must be reachable at

This configuration can be overridden. Download the config archive from our Nexus repository gazelle-sts releases (search for Then unzip the archive, copy the file picketlink-sts.xml under /opt/sts/ and edit its content. As well, the zip archive contains 2 property files named ‘’ and ‘’ containing properties related to assertions such as namespaces, roles, organization, etc. These properties files shall also be copied in /opt/sts/. The content may also be edited to adjust values for defined properties.

Note: The property X509CERTIFICATE of the KeyProvider must stay equals to the SigningKeyAlias property, otherwise the public key declared as issuer will be inconsistant with the private key used to sign the assertion.

Sequoia configurations

Some special configurations have defined in the source code for the Sequoia project. In order to use them, you need to use the ‘’ contained in the zip archive described above, as well as modifying the ‘picketlink-sts.xml’ file to use Sequoia token provider class.

Update from a previous Version

From 1.2.0 to 1.3.0

Add the files and in /opt/sts. More information in the “Configuration” section.


A small SoapUI project to tests the STS web-service can be found on our Nexus repository gazelle-sts releases (search for

The project custom property ServiceBaseURL is used to define the targeted host.