Configure SAML Authentication
SAML stands for Security Assertion Markup Language. It is a current standard for authenticating users in a distributed system.
Stages acts as a SAML Service Provider (SP) and interacts with a SAML IdP (Identity provider) to authenticate users.
Generate a signing key
If you already have a SSL server certificate for Stages, you can use that certificate to sign the SAML requests. If you do not have such a certificate or you want to use a separate certificate, use the follwing command:
keytool -genkeypair -alias "samlkeyalias" -keyalg RSA -keysize 2048 -keystore "conf/saml-keystore.jks"
Enter your Stages URL when asked for the First and Last Name. The rest of the parameters can be set arbitrarily.
You can choose an arbitrary key name (e.g.
samlkeyalias) and location for the keystore (e.g.
conf/saml-keystore.jks), they just need to be the same as you configure below.
Enable SAML for Stages
To configure, add or enable the following section in
<authentication enabled="true" keystore="conf/saml-keystore.jks" keystorePass="changeit"> ... </authentication>
To globally enable SAML, set the
enabled attribute to true. The keystore location and password need to match the keystore from above or your SSL server certificate location.
Configure the SAML Service Provider (SP)
The SAML Service Provider describes your local Stages server.
To configure, add or enable the following section in
<authentication ... <service-provider providerId="<yourStagesURL>" signatureKeyAlias="samlkeyalias" > </service-provider> ... </authentication>
providerId can be an arbitrary name, but it should be globally unique, so it is a good practice to use your Stages URL.
signatureKeyAlias identifies the key to be used for signing the SAML request, so it needs to match either the key you generated above or your server certificate alias. If it is not set, the SAML request will not be signed.
Configure the SAML Identity Provider (IdP)
The SAML Identity Provider describes the remote service that Stages uses to authenticate users. Typically, it is run by the access management group within your IT organization.
The most reliable way to configure the SAML Identity Provider (IdP) is to ask the access management team for the IdP metadata.
From this metadata, you will be able to derive the parameters
- DisplayName (alternative: FirstName, LastName)
for the following configuration:
<authentication> ... <identity-provider providerId="<EntityIDfromMetadata>" providerUrl="<SingleSignOnServiceLocationFromMetadata>" nameIdPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" userFullnameTemplate="%firstname% %lastname%" > <!-- hardcoded magic value that specifies the NameID from the SAML reply --> <identity-provider-attribute name="username" id="http://schemas.stages.methodpark.com/saml/v2/identity/claims/subject" /> <!-- either "fullname" or "firstname" and "lastname" need to be defined --> <!--<identity-provider-attribute name="fullname" id="<DisplayName>" />--> <identity-provider-attribute name="firstname" id="<FirstName>" /> <identity-provider-attribute name="lastname" id="<LastName>" /> <identity-provider-attribute name="email" id="<EMailAddress>" /> <!-- This matches if the SAML assertion contains a SAML attribute "Organization" with value "External" --> <!-- <identity-provider-attribute-match id="Organization" pattern="External" defaultRolesUsername="default_supplier" defaultLicenseType="DEV" autocreateUser="true" /> --> <!-- This is the default matcher, identified by id and pattern attributes set to "*" --> <identity-provider-attribute-match id="*" pattern="*" defaultRolesUsername="default" defaultLicenseType="QM" autocreateUser="true" /> <!-- Specifying at least one certificate automatically enables signature verification of the authentication response. The key data can also be copied from the IdP metadata. If no verifiction-certificate is specified, no signature validation will be performed. --> <verification-certificate> MIIDCTCC... <Insert the X509Certificate "signing" key from the metadata here> ...Qwgf5bXby+ug== </verification-certificate> </identity-provider> <!-- This identity provider statement with the "STAGES" magic id enables local Stages logins to be available for selection between multiple identity providers (NOT IMPLEMENTED YET). If the authentication with the IdP fails and the "STAGES" provider is enabled, the Stages login screen is shown, so the user may log in with a local user id. If it is not configured, the server answers with a 403 (Forbidden) status code. --> <identity-provider providerId="STAGES"/> </authentication>
After you configured the service provider and identity provider in
config.xml, update the configuration via “
stages update” and restart the Stages service.
Generate the SAML SP metadata
After configuring the SAML SP, you can download the SAML SP metadata directly by navigating to the URL
The resulting XML file can be sent to the SAML IdP administrators and contains all information necessary to set up the trust relationship on the IdP side. After the SAML IdP has been configured with the SP metadata, users will be able to authenticate successfully with Stages through the SAML IdP.
Validated IdP Vendors
Stages SAML has successfully been deployed with the following IdP servers:
- Cisco Central Web Authentication (CWA)
- Oracle Access Manager (OAM)
- Shibboleth IdP
Please let us know if you were able to make Stages SAML work with your server and it is not on this list yet.
The default binding type of the SAML-Request is created as a redirect.
Some IDP (f.e. at Renault) doesn´t work with that type and rather need a POST-Request.
This can be configured in the identity-provide section of the config.xml:
There a re no easy options to fint it out, because the IDP only seems to deny the Request (without telling the concrete reason in the response). Only at IDP (→ mostly customer) the problem can be identified.