The internal “user” object
The Wedia system uses the “user” object to represent connected users.
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.
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, 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.
The Wedia object used for authenticating must have a login and password property.
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 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.
When modified, a rule does not affect existing passwords.