Setting up the Authentication

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.