Users' connection to Wedia is based on the following modules configurable using administration interfaces.
There are currently three modules available:
...
It is possible to connect to the Wedia system using user credential stored into a LDAP repository.
Wedia support direct LDAP connection, or Two-steps LDAP connection.
Direct LDAP connection
The direct LDAP connection
...
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 succeed.
Once the different authentication domains have been configured, it is sufficient to activate the authentication system and specify the domain to be used in the Wedia CrossMedia basic settings page as a default, like illustrated below.
...
Connection via 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 parameter: the object name for Wedia CrossMedia to use. By default the user object is used.
...
| Info |
|---|
The Wedia object used for authenfication must have a login property and password property. Passwords are stored in hashe (SHA) and salty (salt common to the server), and it is therefore not possible to return your password to a user, but only to ask him to create a new one. |
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
Edit the current rule if there is one or create a new one by clicking button on the Create a new validation condition button
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.
It is possible to have several password validation 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 password logging option that prevents users from logging passwords to use the same password more than once is available from version 10.5.16 of the motor. This option is activated by adding a new validation rule and selecting the validation engine Historization passwords.
When modified, a rule does not affect existing passwords. In the same way, the rules also do not impact the authorities.
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:
install an LDAP on your machine (windows)
add users to this LDAP
Install an LDAP on your machine (windows)
We will use openLDAP for our test. It can be downloaded here:
http://www.userbooster.de/en/download/openldap-for-windows.aspx (tested version for this article: 2.4.34)
Follow the installation procedure and do not change anything. When finished, you have an LDAP running on your machine in service.
Add users to this LDAP
To avoid having to type obscure command lines, an easy utility to connect to LDAP, LDAP Admin, downloadable here:
link: http://www.ldapadmin.org.
There is no installation, just a program. Run this program as an Administrator.
First step: configure the connection to your LDAP.
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):
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).
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).
Then search for the NOHETO pivot object whose property corresponds to the corresponding LDAP user attribute (parameters 7,8 and 9).
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.
It remains essential to know its structure.
By taking the tree created previously in the example of LDAP installation example (see above), we will configure Wedia Crossmedia to request our LDAP tree, and create users on-the-fly if needed.
...
The first items to fill in are easy:
Additional parameters: none.
Limits the number of attributes read in LDAP. We leave it by default.
LDAP URL: ldap: //localhost: 289
Security level: leave default
Service ID: We use the same string as on ldapAdmin for connect. So we have cn=Manager, dc=maxcrc, dc=com
Password: secret
...
We then see how WEDIA will run the tree:
...
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
...
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.
Authentication workflow using a direct LDAP are described 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):
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).
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).
Then search for the Wedia pivot object whose property corresponds to the corresponding LDAP user attribute (parameters 7,8 and 9).
We initialize the surfer (connected user) from this object.
...
Two-steps LDAP authentication with automatic creation of the local user
The two-steps LDAP authentication will query the LDAP treen, and create the user in the Wedia database on-the-fly if needed.
Here is a breakdown on how this setup is done.
First part of the screen list all the connection parameters to the external DAM :
Additional parameters: none.
Limits the number of attributes read in LDAP. Set to default.
LDAP URL: eg, ldap://localhost:389
Security level: Set to default
Service ID: We use the same string as on ldapAdmin for connect. For example : cn=Manager, dc=maxcrc, dc=com
Password: secret
...
Second part is instructing the system on how the search in the LDAP tree for the user :
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}
...
Third part is how to link the returned record from the LDAP to the Wedia internal user object :
We set up our pivot object (usually “user”)
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
...
Installing a local LDAP to test the connection via LDAP
This article is intented to give a quick walkthrough to system integrator that need to install a local LDAP server on their Windows machine, to test and debug LDAP connections.
Install an LDAP on your local windows machine.
We will use openLDAP for our test. It can be downloaded here:
http://www.userbooster.de/en/download/openldap-for-windows.aspx (tested version for this article: 2.4.34)
Follow the installation procedure and do not change anything. When finished, you have an LDAP running on your machine in service.
Add users to this LDAP
To avoid having to type obscure command lines, an easy utility to connect to LDAP, LDAP Admin, downloadable here:
link: http://www.ldapadmin.org .
There is no installation, just a program. Run this program as an Administrator.
First step: configure the connection to your LDAP.
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.
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:
A user appears on the WXM connection chart,
It clicks on a SSO SAML2 provider,
This user arrives on the connection chart of the identity provider SAML2,
This user logs in,
It is redirected to WXM,
It is searched whether there is a WXM user corresponding to the SAML2 user according to a matching rule configured in WXM,
If the user does not exist, it is created automatically with a combination of attributes retrieved from the SAML2 authentication or imposed upon creation,
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
Go to the configuration screen
Go to the Administration homepage: admin/ebnAdminTools.ebn.
Click Authentication service on the Server Configuration tab
Click the Identity Provider tab
Create a new identity provider
Click Add New Identity Server.
Choose SAML2 as the supplier type.
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:
Deploy your webapp with the same context as the target machine: traditionally ROOT.
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
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
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.
...
| View file | ||
|---|---|---|
|
OAUTH2 Connection
The content of this article is only valid from version 11.5.3 onwards.
...
It is possible to use a subproperty of the JSON profile as a value of mapping by specifying its full path in the form:
Prop. under_prop. under_sub_prop.
Ex: address. city
SSO connection with SAML or OAuth: how to manage a validation step of new users?
The content of this article is valid since WEDIA 11.5.3
...
The procedure for this clientf case is as follows:
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".
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.