Page Comparison

SAML2 authentication

Preamble

This documentation briefly explains SAML2 authentication to configure WXM Wedia to connect via a provider of SAML2 identities. It is not intended to be used as documentation on SAML2. Please refer to the official documentation.

Terms used in this documentation:

• Service Provider

...

• : SAML Authentication Client

...

• : Wedia

• Identity Provider

...

• : External system used to authenticate a user.

SAML Authentication

...

First of all, SAML2 authentication does not change the object model about users / groups in WXM but is grafted on top. This means that it is not necessary to integrate SAML2 authentication early in the life of a project. It can be grafted at the end of it.

The general principle is as follows:

...

A user appears on the WXM connection chart,

...

flow in Wedia

A login with SAML follows this typical scenario :

1. A user open the Login page provided by Wedia

2. The user clicks on a SSO SAML2 provider listed in the login page,

3. This user arrives is directed on the connection chart page of the identity provider SAML2,

4. This user logs in on this page,

5. It The users is redirected to WXMWedia,

6. It is searched whether there is a WXM Wedia searches for a user corresponding to the SAML2 user, according to a matching rule configured in WXMWedia,

7. If the user does not exist, it is created automatically with a combination of attributes retrieved from the SAML2 authentication or imposed upon creationassertion, or default values,

8. The user is logged in, and can normally use WXM.

What to prepare before configuring SAML2

...

1. use Wedia (It is also possible to set up an additional accreditation step)

Collecting attributes from SAML assertion to map to the local user

Before setting up the SAML connection, it is important to list which attributes coming from the SAML authentication server will be replicated into the Wedia user.

...

A single attribute is required for the connection to work "Name-ID." It should generally correspond to a local attribute allowing to uniquely identify a user (e.g. : login) but it will be possible to very well choose another attribute for that like email.

...

Similarly, URLs that are not in https can be refused by the identity provider. This is the case with ADFS.

How to configure SAML2

...

Go to the configuration screen

...

Go to the Administration homepage: admin/ebnAdminTools.ebn.

...

Configuring a SAML2 connection

Follow these steps to set up a SAML2 connection :

1. Login to the /admin configuration screen

2. Click Authentication service on the Server Configuration tab

3. Click the Identity Provider tab

Create a new identity provider :

1. Click Add New Identity Server.

2. Choose SAML2 as the supplier type.

3. Give this supplier a name. Choose the good because it is the name that This name will appear on the WXM login pagescreen presented to the user.

Export of the service provider’s metadata

In the Service Provider column, enter the service identifier and the size of the encryption and encryption keys for SAML2 envelopes as in the example below.

To export the metadata that will be sent to your identity provider, click on Export metadata.

...

The service identifier is the name of this service provider at of an identity provider. The format is free and must not be modified after the implementation of SAML2 authentication. Encryption and encryption key sizes can be adapted to suit the following requirements the level of encryption based on the provider’s capabilities identification and legislation in force for installed servers.Warning

...

To export the metadata to be sent to your identity provider, click on Export metadata.

Importation of metadata Metadata import from identity provider or manual information

The configuration is done in the right column as in the screenshot below.

...

Otherwise, you must manually enter the login/disconnect URLs as follows that the identity provider’s encryption and/or signature certificates in X.509 format.

Mapping of the SAML2 / local attributes.

This part consists of:

must

Must → define the local object with the user’s info. By default, this object is user.

obligatory

Obligatory →fill in the SAML2 attributes and local "pivots" allowing you to find a local user corresponding to the user identified by the identity provider.

Optionally

Optional →add additional matches that will allow you to import SAML2 attributes into local user attributes when importing SAML2 attributes into local user attributes of a user’s first login.

Pivotal Pivot attributes

For the mapping of pivotal attributes, good configurations are:

• Name-ID (SAML2) =⇒ → login (local).

• Email (SAML2) =⇒ → email (Local)

The rules for selecting these fields are as follows:

• SAML and local pivot fields must be capable of identifying in such a way that a single user.

• The SAML pivot field must be persistent (important in the case of Name-ID). In other words, a user must always obtain the same value for these fields.

Additional attributes

The additional attribute mapping is optional: it has no effect on the proper functioning of SAML authentication. However, it is interesting to be able to retrieve information from the user to create the local user. Typically, the name, the first name, and email are information we’ll want to get back.

...

The configuration of the initialization values is quite limited in this screen. For more advanced treatments, it is best to create a trigger in beforeInsert on the object to initialize (in this case: user).

...

...

ADFS configuration

On the ADFS side, a good claim configuration is:

• SAM-Account-Name ⇒ NameID

• User-Principal-Name ⇒ E-Mail Address

• Display-Name ⇒ Name

WXM Wedia side:

• Name-Id ⇒ login

• Email ⇒ email

• Name ⇒ name

How to test SAML authentication outside the production server

It is sometimes desirable to test new developments on the creating or updating users via SAML without affecting servers of production. The SAML protocol makes it easy to carry out these tests on an development environment by making a few modifications on his workstation localSetting up a development server for testing a SAML connection

As a software integrator, it can be interesting to run a local SAML connection for testing.

The procedure is as follows:

1. Deploy your webapp with the same context as the target machine: traditionally ROOT.

2. Edit your hosts file to point the URL of the target server at your development environment by adding a line of the type: 127.0.0.0.1 monserverdeprod

3. Access the login URL as if you were going to the production server (remember to switch to https if necessary). E.g.: https://monserveurdeprod/wcm.jspz

4. Remember to delete the modification of the hosts file at the end of your tests to access the production server again.

SAML2 authentication via Shibboleth Identity Provider

This article is not intended to explain the installation of the application Shibboleth Identity Provider but to present the key points to enable authentication via this identity provider from a WEDIA application.

...

If you have any questions, please do not hesitate to refer to the WIKI of installation / Shibboleth configuration: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPConfiguration

This parameter setting documentation has been tested on Shibboleth Identity Provider versions 2.4.0,2.4.1 and 2.4.3. It does not cover documentation for 1. x versions depreciated since 2010 or future 3. x versions.
Logging if necessary

WIKI: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPLogging

• Passing the edu. internet2. middleware. shibboleth logger in DEBUG

• Pass the edu. vt. middleware. ldap logger to DEBUG

• Discomment the logger PROTOCOL_MESSAGE and pass it to DEBUG

...

Configuration of relying-party. xml

WIKI: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty WIKI: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPMetadataProvider

Add a new RelayingParty AFTER the DefaultRelyingParty element that will represent the WEDIA application for which we wish to offer the SAML2 identification functionalities (this is the SAML service ID) in the WEDIA configuration).

...

attribute-resolver. xml configuration

WIKI: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAddAttribute

This file is used to define how to retrieve attributes from the data source, here LDAP.

...

attribute-filter configuration

WIKI: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAddAttribute

This file describes which attributes will be exposed to suppliers of services.

...

Configuration of handler.xml

WIKI: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPass

This file allows you to define the methods that will be used to identify a user

...

login.config configuration

WIKI: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPass

Describes the method for authenticating the user to LDAP by connecting to the LDAP server.

...

edu. vt. middleware. ldap. jaas. LdapLoginModule required
      ldapUrl="ldap: //MONSERVEURLDAP: 389"
      baseDn="cn=Users, dc=RD, dc=local".
      bindDn="cn=Administrator, cn=Users, dc=RD, dc=local".
      bindCredential="**************************"
      ssl="false"
      tls="false".
      subtreeSearch="true"
      userFilter="(& (objectclass=person)(sAMAccountName={0}))";

Configuration of SAML connectors in WEDIA

Create a new SAML connection, the name of this new connection is free.

...

by replacing USERNAME with the login of a known user in the system, SAML2 attributes will be displayed in the console. If no attribute is returned, there is a problem in the configuration. Check the error messages and other logs in /opt/shibboleth/logs (think of activating the shibboleth logs to find the source of the anomalies).

Start the tomcat server of the idP

Click on the Test SAML2 Connection button and log in with a known user on LDAP, the configuration will reload.

...