User Authentication

One of the system administrator responsibilities is to ensure the system has a user authentication method in place. When starting the application, it must know if the user is entitled to use the application and must identify the user.

• The three types of authentication are:

• LDAP authentication (using the Active directory)

• OAuth2 authentication (using authorization with another site)

• Database authentication (stores users and passwords in mongoDB)

• The authentication mode is determined in the Global Settings function in the Administration > Administration block. For more information, see the Global Settings topic in this document.

LDAP authentication

With LDAP Authentication, the user enters their user name and password when prompted and the following authentication steps are taken:

• If there is no instance of the login name, the user cannot log in.

• If there is an instance, the system performs an LDAP search for the user’s distinguished name and identifies the user in the LDAP structure.

• If an authentication name is provided, the name is used for the search; otherwise, the login name is used.

• If the entry is found, and LDAP authentication is performed and if the authentication succeeds, the user can use the application.

• If you are using LDAP authentication, you must define the LDAP servers using the LDAP Servers function in the Administration > Administration block.

• For the LDAP server, you must enter a name and display name as well as the URL.

• The URL is made up of the server name, port, and protocol.

• You must also define the distinguished name and password of an LDAP user which has the rights to search the LDAP tree.

• The search filter defined determines the search condition that must be met for the user authentication.

• You can also define mapping information that can be used if you want to import users from LDAP.

• To test the connection, click Connection test.

How are users imported from LDAP?

To run this function, the current LDAP entry must be active and you must have write
access to the user data. If this is the case, the program will perform the following
processing:

• A list of LDAP user data will be retrieved from the LDAP server using the pattern in the Sync search filter field within the subtree defined by the Search Base field for authentication.

• For each user, the value of the user account is used. The program checks if there is an entry of the LDAP user data with this value of the LDAP attribute in which the user account has been mapped. The user account is the Authentication name if the user has LDAP authentication selected by default and if the field is not empty; otherwise, it will be the login code.

• If there is such an entry, all values of the above user instance attributes will be filled from the corresponding values of the LDAP user data attributes. Moreover, the LDAP user data entry will be marked as used and the user instance will be marked as active.

• If there is no entry of the LDAP user data for a user whose authentication is performed using this LDAP instance, it will be marked as inactive and the user cannot login anymore.

• At the end, there will be a loop over all LDAP user data entries which have not been marked as used. These correspond to users that still have to be created. If there is already a user whose login name is the same as the value of the authenticationName, a login name will be created as follows:

• All instances of the user entity will be retrieved whose login name starts with the given value, then the lowest number from 1, 2, ... will be appended to the login name for which there is no user with this login name. For example, if the name is "test" and there are already users test, test0, test1, test3, testa, then 2 will be the lowest number, and test2 will be the new login name.

• The authenticationName will not be changed because it is used for LDAP authentication. The above mechanism for existing users guarantees that user data will be updated correctly when this function is called again. If a new user has been created by another connection while the searching user entity process is in progress, there will be an error message. There is no loop that tests each possible combined user name, whether it has already been created, so that endless loops will not be possible under all circumstances.

• For the other attributes (first name, given name, mail, photo), the value in the user instance will be updated when a mapping is given and there is a value for the LDAP attribute. When the mapping is given but there is no value for the LDAP attribute, the value in the user instance will be emptied. When no mapping is given, the value in the user instance will not change.

• At the end, when all users are managed, all error messages are displayed.

OAuth2 authentication

Different than LDAP authentication, with OAuth2 authentication, an application is granted confidential information about a user.

• Before it can be used, the application must be registered with the OAuth2 server to obtain access.

• For the registration, a redirect uniform resource identifier (URI) and the data which the application obtains from the server must be provided.

• The OAuth2 server provides a client ID and a client secret. 

• When the user logs into the application, the following process is followed:

1. The application redirects the user to the OAuth2 server and provides the client ID from the registration.
2. The OAuth2 authorization server asks the user to log in unless the user is already logged in with the OAuth2 server.
3. The OAuth2 authorization server asks whether the application may obtain the data which has been mentioned in the registration procedure.
4. If the user approves, the OAuth2 authorization server sends an authorization code to the redirect URI, which has been registered. The OAuth2 authorization server tells the application that the user is OK and is willing to provide the data.
5. The application has to authenticate with the OAuth2 authorization server by sending the authorization code together with the client ID and client secret to the OAuth2 authorization server.
6. If the data is correct, the OAuth2 authorization server answers with an access token (invisible to the user). The access token entitles the application to obtain confidential data such as the user name.

• If you are using OAuth2 authentication, you must define the OAuth2 servers using the OAuth2 Servers function in the Administration > Administration block.

• For the OAuth2 server, you must enter a name and display name as well as the URL without the path.

• The URL is made up of the protocol name, server name, and port number.

• You must also define the path for authorization and to get the access token.

• Information such as the client ID, client secret, and redirect obtained during the registration of the application on the OAuth2 server is also defined.

Database authentication

With database authentication, a user password is entered and stored encrypted in the
mongoDB database.

• The user password is defined when setting up the user in the Users function in the Administration > Administration block.

• Unlike the other authentication methods, you can require the user change their password in the Users task.

• When changing the password, a user that does not have write access to the users table, must enter the old password before entering a new password.

• A user with write access to the users table can enter a new password without entering the old password.

-
Sage X3 and Sage Software are trademarks of Sage Software, Inc. Microsoft SQL Server, Microsoft SQL Enterprise Manager and SQL Server Management Studio are registered trademarks of Microsoft Corporation. Oracle is is a registered trademark or Oracle Corporation. All other product names used here are trademarks or registered trademarks of their respective owners.

-