It 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.
| Info |
|---|
Users typically hold metadata about the user (names, emails, …), and you should be aware that extending this object with more personal information needs to be reported in GDPR reports. |
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.
...
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, you will need to check if the authentication system 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 login/password.
This connection module requires only a single parameter: the object name for Wedia to use. By default this is the user object.
...
| Info |
|---|
The Wedia object used for authenticating must have a login and password property. |
| Info |
|---|
Passwords are stored in hashes (SHA1) and salted (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. |
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" 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 multiple rules active at the same time, 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
: 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.Status colour Purple title 10.5.16
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.
When modified, a rule does not affect existing 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:
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
...
Wedia support direct LDAP connection, or Two-steps LDAP connection.
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.
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
...