Principle

The management of authentications and access to the solutions based on the SAFE X3 technology rests on two complementary principles:

1) Centralizing the authentication data

In order to manage the users authentication in the SAFE X3 software in a centralized way, it is possible to store some information in a directoryLDAP ( Lightweight Directory Access Protocol). This centralization can be carried out whatever the connection type.

2) The single sign on (SSO)

It is possible to consider that a user who logs in his/her workstation running with Windows has already signed in (the user has entered his/her password). As a consequence, the user does not want to enter his/her user code and password again every time he/she wants to be connected to SAFE X3.

Signing in once is called SSO (Single Sign-On).

Limitations

Today, the SSO works in two cases:

  • for the connections in client-server, as soon as the parameters have correctly been implemented
  • in Web mode, provided that the user is connected to a secure network (private or internal network) and that the protocol NTLM over http has been implemented (defined in the console).
  • using SSO Sage (this is possible in web service for Netvibes; in that case, the Sage service certifies an email address that will be used as an entry point. The parameters of the directory will only be used to proceed to an additional check and an update of the ERP fields stored in the directory.

These functionalities can be implemented for Sage X3, by means of a group of parameters.

Description

The connection process as described here, corresponds to what happens in client-server mode, as soon as the corresponding parameters described in the following paragraphs have been defined.
The various phases unfold as follows:

1 - The user logs in (under Windows, for example with 'john_doe'; in Web mode because the NTLM layer recovers the account).

2 - The user opens a SAFE X" software session by double-clicking on the launch icon (or by clicking on a hyperlink). In client-server mode, the connection window opens (at least the first time! by clicking on the box "use these parameters for the next connection", the connection box will no longer be displayed then, except when pressing the [Shift] key during the launching).

3 - If it is set in client-server mode, the user enters his/her user code as it is known in the software. The code can be JOHN, DOE, ADMIN, or any other code, but if the user wants to implement the SSO, the user code has to be JOHN_DOE.

4 - The software checks that JOHN_DOE exists in the user table (the field tested is the Login field in the user table). For instance, this code corresponds to the user code JOHND. The code JOHND (5 characters maximum) is stored in all the tables in which the AUS data type is used.

5 - Once the SSO has been activated and the JOHN_DOE code (corresponding to the original login) has been entered, the password control is no longer carried out (it is carried out in a blocking way if the user code does not correspond to the login system).

6 - The system uses then the Reference Active Directory field of the user to inquire the centralized directory (LDAP, Active Directory ... according to the global parameters of supplied connections), and recovers a group of values in return (field values of the user table, setup values at the level of the user). It updates these values in the software if they have been changed in the directory (since the directory is the reference).

Setup values in folder

Setup values in folder

To implement the user directory, the following setup values must be entered in the folder.

SSO connection

The setup value SSOCONNECT is used to activate the function SSO / LDAP from X3 (i.e. the connection to the centralized directory).

The possible values are:

  • Non: The SSO/LDAP connection is inactive,
  • Interactive: The SSO/LDAP connection is only active in interactive mode (C/S and Web)
  • Interactive and Web service: The SSO/LDAP connection is active in interactive mode and also for the Web services.
Directory code

The SSODIRECT setup value contains the directory code when the SSOCONNECT setup is active. It refers to the table that defines the directories and the possible connections.

user update at the connection

The SSOMAJ setup value (Yes/No) is used to determine if the update of the user record and the user setup values must be carried out at each X3 user connection.

If its value is set to No, and if the other parameters are active, the system will check if the user exists in the directory without triggering the update of parameters and user values at each connection. The update will be carried out in batch mode thanks to the batch task ASSOMAJ which will have to be abandoned.

SSO password control

The setup value SSOPASSWD (Yes/No) is used to force the control (and so to impose the entry) of the password in client-server mode even though the user code entered in the connection box is the same as the user's Windows login.

In Web mode, the control is systematically carried out.

Setup values for users

Only one parameter may be modified at users' level.

Domain

The parameter value SSODOMAIN, if it is not void, enables the limitation user connection from a given domain. If it is not void, only the user is controlled, not the domain.

Reference for user update

The information of a LDAP directory are displayed as a graphical tree.
Each node from the tree is an abstract or real object (an individual, a group of people, a printer, parameters,...).The DN (Distinguished Name) of an object is a way to identify an object in a unique way in the hierarchy.
This first identifier is stored in the user record. The field isAUTILIS.ADDNAM.

SEEINFO A second identifier is set up in the directory and, generally speaking, it is the login.

Below, an example of an LDAP menu. It is required to note that the hierarchies can be defined freely, and that such a directory can reference either users, or groups, or resources (such as printers). Inquiring such a menu is carried out by indicating a search root, and then by requiring a search on the node itself, on its direct descendants, or on all the subtree from the specified root. The starting node and the way to search the information are specified in the directory setup.

./LDAP_schema.jpg

Connection principle

Let's consider that the SSO mode is active and that a X3 user is connected for the first time to the SAFE X3 application.

The X3 application, when connecting, checks that the login entered exists in the directory. If yes, the application recovers the DN (Distinguished Name), which is updated in the ADDNAM field of the AUTILIS user table.

If the SSOMAJ setup value is set toYes, all the 'mapped' fields are updated in the user record and in the X3 setup values.

User directory function

Access to the LDAP server

The "Directory" function is used to define the configuration in order for the X3 application to be able to read the information included in the LDAP directory.

The fields mapping

A correspondence is carried out between the fields of the user table, the user setup values table and the LDAP directory fields.

Additional functions in batch

The ASSOMAJ task is used to update the users compared with the LDAP directory.

SEEWARNING Only the existing users in the AUTILIS table will be updated; this utility does not create new users by reading data from the LDAP directory.

The link is carried out by the DN (Distinguished Name) if it is already entered in the user table. Otherwise, the second identifier set up (generally the login) is used to find the DN.

Distinguished Name

The structures below describe in detail the different possible cases of connection, as well as the corresponding control procedures.

./connection_fra.jpg