Page Comparison

Users' connection to Wedia is based on the following modules configurable using administration interfaces.
There are currently three modules available:

• Traditional connection via an object containing a user/password.

• Direct LDAP connection

• LDAP connection in two passes

A fourth module is available as an option and allows you to log in against a user directory managed by Google Apps.

These different modules are explained in more detail in other articles in the this chapter.

It is also possible in each module to specify another module to use if the first one fails. This makes it possible to link different authentication methods in the event of an LDAP server unavailability or simply to multiply the authentication sources.

It is important to note that whatever authentication method you choose, it is always necessary to have an object in the base representing a user even if authentication is done using an external mechanism.

This object is called: the pivot object in the documentation of the modules of the external connection. This pivot object must always have shared ownership and the same value as a user attribute in the external system.
Without this prerequisite, authentication in Wedia CrossMedia will never succeedIt is possible to connect to the Wedia system using user credential stored into a LDAP repository.

The internal “user” object

The Wedia system uses the “user” object to represent connected users.

Even when using an external repository, Wedia still needs a data object that will represent the user. By default, this is the “user” object, but as it can be replaced by another table, we will refer to this object as the “user pivot”. This pivot object will be used to connect the Wedia internal information, with the external LDAP information.

Authentication “domains”

Multiple ways of authenticating can be configured into the Wedia system : for example, an internal login using a login / password stored into the user object, a first LDAP directory, a second LDAP directory… Each authentication mean is called an Authentication Domain.

Authentication domains are chained, meaning the Wedia system will try the first domain to autenticate the user with the credentials, then the second, etc. until an authentication domains returns a positive authentication, of all fails.

Once the different authentication domains have been configured, it is sufficient to activate you will need to check if the authentication system and specify the domain to be used in the Wedia CrossMedia basic settings page as a default, like illustrated below.

...

is activated (this is the default setting), and which Authentication Domain should be the first to be tested:

...

Authentication via the internal user object

This connection is the traditional method of authentication. It consists of to authenticate a user using a database object via a couple login/password.

This connection module requires only one a single parameter: the object name for Wedia CrossMedia to use. By default this is the user object is used.

...

Validation of passwords

When using the system’s standard authentication system (based on the WEDIA/NOHETO identification engine and therefore incompatible with LDAP systems or other external authentication systems) it is possible to set the following options place rules for password validation.

These rules make it possible to define, for example, the minimum number of characters that must have passwords in the application, the number of digits, uppercase or lowercase characters or punctuation characters they use must contain.

Access to the rules engine is located in the section Server Configuration > Administration > Authentication Services of the the application (/admin).

...

Go to the admin part of the application in the Configuration section of the server > Authentication services

...

Then go to the tab Validate new passwords

...

Setting the requirements for internal passwords

It is possible, when using the internal User database authentication, to setpassword validation rules for the standard authentication system of the system.

To access the rules engine, go to the "Server Configuration" > "Administration" > "Authentication Services" section of the application. From there, you can either edit the current rule or create a new one by clicking

...

the "Create a new validation condition

...

Select the validation engine Basic constraints

...

Give a name to the rule and select the options you want to give.
For all new passwords in the application: minimum length, number of digits, lower case, upper case, etc.

...

Click the Save button.

" button. When creating a new rule, you can give it a name and select the desired options for password validation. It is possible to have several password validation multiple rules active at the same time. If this is the case, they will add up to each other.

Optionally it is possible to activate an option that will force the users to change their passwords every X days by changing the parameter.
The maximum number of days before changing the password can be configured in the tab Global settings.
If the value of this parameter is equal to 0, the system will never ask users to change their passwords.

A , in which case they will be combined.

These rules can be used to specify requirements for passwords, such as :

• minimum length,

• complexity : number of uppercase, lowercase, and punctuation characters they must contain,

• prevent password reuse : since version

  Status
  colour Purple title 10.5.16

  : there is also a password logging option that prevents users from

...

• reusing the same password more than once

...

• .

...

• This option

...

• can be activated by adding a new validation rule and selecting the

...

• "Historization passwords" validation engine.

There is also an option to force users to change their passwords every certain number of days. This option can be configured in the "Global Settings" tab. If the value is set to 0, users will never be prompted to change their passwords.

Install a local LDAP to test the connection via LDAP

This article is not intended to be a substitute for the literature on setting up an LDAP connection. It gives a procedure for:

...

• From the menu, Start > Connect or connect icon

  

• Click to create a connection

  

• Give it a name

  

• Fill in the host, and the port (initially localhost and 389)

  

• Click Fetch DNS to help you enter the database

  

• Test the connection

  

• Uncheck Anonymous login to fill in the Username and the Password. To determine the username, the simplest way to determine the username is to use a user with the maximum of rights. If you did not change anything during the installation of openLDAP, this connection string is:

  cn=Manager, dc=maxcrc, dc=com

  Indeed, it must be possible to identify the user with which you want to connect by specifying its position in the tree. In the case of the Manager, it is identified via his name (Manager) and the base of our tree. If you don’t have nothing changed during the installation, his password is secret.

  

• Click OK

  

• The connection is available, you can open a connection at your tree as a Manager

  

• Once logged in, you can create groups and users. Here is an example of a tree created by filling in forms for each type.

  

Direct LDAP connection

The direct LDAP connection consists of using the username/word pair of user’s password to connect to the LDAP server and possibly validate its membership in one or more groups. For reasons of access rights to the LDAP server, the connection in two passes is used more frequently.

Authentication kinematics are described below. Each step refers to the parameters it needs. These settings are entered in the screenshot below. Failure of any of these steps will result in failure of authentication or delegation of authority or authentication to the next authentication domain (parameter 12):

1. Login with login / password of the user. The login is injected into the dn model to create the real ldap connection identifier (parameters 6 and 11).

2. If the validation of the user group is enabled, these groups are searched by injecting the user’s dn into the search criteria (parameters 2,3,4 and 5).

3. Then search for the NOHETO pivot object whose property corresponds to the corresponding LDAP user attribute (parameters 7,8 and 9).

4. We initialize the surfer from this object.

...

2-step LDAP authentication with automatic creation of the local user

Once your LDAP is installed and operational, it is very simple to use it directly in Wedia CrossMedia.

...

• Recursive search of the user: set to true if all users do not use it or are not on the same level

• User’s root: at this level we specify from where we search users, which avoids having to go through the entire tree. In our case, we decide to search from the Wedia group. In this LDAP, the group is named or. Our request is therefore or=Wedia, dc=maxcrc, dc=com

• Don’t forget that you must always specify full access to the branch.

• User search criteria: We chose to log in using the login or uid. The chain is therefore positioned so that WXM can build it: uid={0}

  This is then linked to the local structure:

  

• We define our pivot object (to be used)

• The pivot LDAP attribute: it is the attribute that will allow us to find the following attributes the user. Here the mail, but could be the login (guided in our tree)

• the pivot wedia property. the mail in the user structure is stored in the field email. If we had chosen the login, we would write login

• Is it necessary to create the user locally

  • If false, it means that in order to be able to connect, the user must already be integrated in our local database.

  • If true, it is possible to create it if you can’t find it

• Filling Properties: A JSON that gives LDAP mapping of WXM and allows you to fill in static data.
  This JSON is an array, each value an object with 2 properties:

  • fieldNoheto (required): the name of the property in the user structure to be fed.

  • attLdap: the name of the LDAP attribute to be used to fill this value

    or

    static: a static value

SAML2 authentication

Preamble

This documentation briefly explains SAML2 authentication to configure WXM 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.

...

Site used to authenticate a user.

Authentication principle SAML2 in WXM

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:

1. A user appears on the WXM connection chart,

2. It clicks on a SSO SAML2 provider,

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

4. This user logs in,

5. It is redirected to WXM,

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

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

8. The user can normally use WXM.

What to prepare before configuring SAML2

...

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

How to configure SAML2

1. Go to the configuration screen

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

3. Click Authentication service on the Server Configuration tab

4. 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 will appear on the WXM login page.

Export of the service provider’s metadata

...

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.

...

The configuration of SAML2 is complete, your users will be able to connect to the WEDIA application by clicking on the button provided for this purpose on the WEDIA application login page.

The Google Apps connection

A plugin allows to connect in SSO via the system proposed by Google Apps.

...

OAUTH2 Connection

...

SSO connection with SAML or OAuth: how to manage a validation step of new users?

...

The procedure for this clientf case is as follows:

1. In mappings for automatic creation of a user or in a trigger "before insert", the field "activated" must be set to "activated" by the user to "false".

2. In this case, the authentication procedure (positive feedback from the server of identity) an instance of "wsnoheto. engine. engine. login. sso. UserDisabled" is added to the session in the attribute "wsnoheto. engine. login. sso. UserDisabled". This object (present in the user JAVADOC) makes it possible to find the object fresh user created in the inactive state. It is enough to exploit this session attribute in your login page to display information on the validation process to follow for your user.