Properties of applications: Application authentication
On the Authentication tab, which is present when you have selected a new or existing application in the Application browser, you specify the login procedure for opening your Collections application. Axiell Collections always opens with a login screen in which a user name and password have to be filled in, unless you use single sign-on. The applicable user credentials can have different origins. See the Help topic: User authentication and access rights, for more information about access rights.
Click here for information on how to edit properties in general. On the current tab you'll find the following settings:
• | None - the (for Collections) inappropriately named "None" option, means that Collections will validate an entered user name and password to user credentials from the local machine or Active Directory. The relevant credentials will then be used too for applying any security policy through access rights and roles. Users must still be linked to roles, which can be done in the application structure (.pbk). |
• | Adlib.pbk - store user names, passwords and roles in a Collections .pbk file through user properties editable in Designer. The user names may be different from user names for the general Windows login. Two-factor authentication can be set up for this authentication method. |
• | Adlib database - store user names, passwords, roles (optionally) and application ids (optionally) in one of your Collections databases. You'll probably have to adjust your application to make it possible to enter this information in the database. You'll then have to fill in the other options on the current properties tab. The user names may be different from user names for the general Windows login, but user names need to be unique. The Change/Reset password functionality as well as two-factor authentication can be set up for this authentication method. |
• | Active directory - store user names, passwords and possibly e-mail addresses in Active directory user accounts. Users must still be linked to roles for applying any security policy in Collections itself, which can be done in the application structure (.pbk). The Change/Reset password functionality as well as two-factor authentication can be set up for this authentication method. |
• | HTTP - this option cannot be used in Axiell Collections. |
• | Single SignOn - using the user authentication services of an external so-called identity provider like Azure Active Directory, Collections applications can be set up for single sign-on functionality. After a proper setup, this option allows the user to log into Collections without login dialog if he or she is already logged into a different online application in that browser using the same identity provider. The use of external authentication services is not included in your Axiell license and setup of this functionality is complex, so please consult the Axiell ALM Sales department for more information. |
See: User authentication and access rights, for more information about authentication methods.
Only if you've selected the Authentication method: Adlib database, this property must contain the full path to the database you want to link to, without the name of the file. You don't have to fill in this property manually: just select a database in the next option, and the path to that folder is automatically entered here.
First, enter or search for the name of the existing database table (an .inf file name) that holds all the user names and passwords (only for the Authentication method: Adlib database). Do not enter the extension of the file. An example of such a database name is PEOPLE.
If the database that you select has datasets defined for it, these datasets will be listed in the Dataset drop-down list. (Some databases may not have datasets.) Selecting a dataset is optional, you can also just link to an entire database. Typically, you select a dataset if for this link you only want to retrieve data from that specific dataset.
In the above chosen database table (only for the Authentication method: Adlib database), select the (existing) data dictionary field that holds all user names.
See: User authentication and access rights, for more information.
In the above chosen database table (only for the Authentication method: Adlib database), select the (existing) data dictionary field that holds all passwords.
See: User authentication and access rights, for more information.
In the above chosen database table (only for the Authentication method: Adlib database), select the (existing) data dictionary field that holds all user roles.
See: User authentication and access rights, for more information.
In the above chosen database table (only for the Authentication method: Adlib database), select the (existing) data dictionary field that holds all application ids.
An application id field is only necessary if users must have different roles in different applications. The user role and application id fields must then be grouped and be repeatable.
See: User authentication and access rights, for more information.
If you are using the Adlib database authenthication method, then for the password resetting functionality and/or two-factor authentication (via e-mail) in Axiell Collections to be functional, an e-mail field is needed in the above specified authentication database table to store the e-mail address of the user to whom a password reset or authentication e-mail must be sent. An e-mail Server, Port number and Sender e-mail address must also be filled in.
For the Active directory method, e-mail addresses of users need to have been specified in their Active Directory accounts: per account only one e-mail address can be used, so authentication by Active Directory groups might not be a good idea.
See the general Setup of password reset functionality topic for more information.
This option is intended for future password resetting or two-factor authentication via Mobile app or SMS, but this is currently not functional yet.
This option is only relevant to the HTTP authentication method which is not supported by Axiell Collections.
For two-factor authentication functionality in Axiell Collections, a provider is required. E-mail is the only option you can use: Mobile App and SMS are currently not functional yet. Leave the Provider to None if you don't want to switch this functionality on. See the general Setup of password reset functionality topic for more information.
In an entreprise environment where different Collections applications cannot be allowed direct access to Active Directory, a separate authentication service with its own access to Active Directory is recommended: password reset requests from the normal Collections applications will then be passed on to this authentication service.
If you'd like to use an authentication service (a separate Collections installation on the local network for example, solely used as an authentication service, or a third-party authentication service) for the password resetting functionality and two-factor authentication in Axiell Collections, you can specify it here. Also set the Provider option to E-mail.
An authentication service for two-factor authentication can be used with either the Adlib.pbk, Adlib database or Active Directory authentication method.
An authentication service for password resetting can be used with either the Adlib database or Active Directory authentication method.
You can leave this option empty to let the current Collections installation handle the authentication.
Just install another Collections application similar to the ones you already have, but for password resetting its application pool user needs to have write (and read) access to Active Directory to allow it to change passwords. (By default the Collections application pool user, when it is an Active Directory Service Account, is not allowed to manage user passwords. Therefore you need to "delegate" this management to that user in Active Directory. See the general Setup of password reset functionality topic for more information about this.) For two-factor authentication you need to provide the URL to your new Collections authentication application as the Authentication server in the adlib.pbk, for example:
The settings.xml file of a Collections authentication server (if it is a separate Collections instance for this purpose only) must be changed to resemble the following:
<?xml version="1.0" encoding=”utf-8” ?>
<Settings xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Configuration>
< Setting Key="BasePath" Value="\\ourserver\axiell\model 4.5" />
</Configuration>
</Settings>
In which the base path Value must be changed to the UNC path under which your regular Collections applications have been installed.
Enter the name of your SMTP server, to be used for sending e-mails for two-factor authentication, password resetting functionality and SDI functionality (the latter from Collections 1.12).
You must have an SMTP server to be able to use this method of sending e-mail. Enter its name in the Server property and also fill in the Port number (typically 25, but your system administrator will know for sure) and the desired Sender email address. See the general Setup of password reset functionality topic for more information.
If the Collections task scheduler functionality has been set up for running import jobs in the background and to execute SDI tasks with Collections integrated SDI functionality (available from version 1.12) - this is different from the SDI functionality provided by the now deprecated sdi.exe - then the SMTP Server, Port number and Sender email address options must be set to allow SDI results to be sent via e-mail.
Enter the port number of your SMTP server to be used for sending e-mails for two-factor authentication, password resetting functionality and SDI functionality (the latter from Collections 1.12).
You must have an SMTP server to be able to use this method. Enter its name in the Server property and also fill in the Port number (typically 25, but your system administrator will know for sure) and the desired Sender email address. See the general Setup of password reset functionality topic for more information.
If the Collections task scheduler functionality has been set up for running import jobs in the background and to execute SDI tasks with Collections integrated SDI functionality (available from version 1.12) - this is different from the SDI functionality provided by the now deprecated sdi.exe - then the SMTP Server, Port number and Sender email address options must be set to allow SDI results to be sent via e-mail.
Mark this option (available from 1.13.1.6603) to have the SMTP client (Collections) create a TLS/SSL connection to the SMTP server, to enable secure connections for e-mails sent through SMTP. This setting is compatible with Collections 1.19 and up.
Since the connection needs to be authenticated via user credentials (user name and password) other than the IIS application pool identity credentials, you'll have to use a so-called secrets store to securely store these credentials (or other sensitive information) in, for Collections to use when a connection must be made for the currently logged-in user. Click here for the full topic.
Enter the sender e-mail address to be used for sending e-mails for two-factor authentication, password resetting functionality and SDI functionality (the latter from Collections 1.12).
You must have an SMTP server to be able to use this method. Enter its name in the Server property and also fill in the Port number (typically 25, but your system administrator will know for sure) and the desired Sender email address. See the general Setup of password reset functionality topic for more information.
If the Collections task scheduler functionality has been set up for running import jobs in the background and to execute SDI tasks with Collections integrated SDI functionality (available from version 1.12) - this is different from the SDI functionality provided by the now deprecated sdi.exe - then the SMTP Server, Port number and Sender email address options must be set to allow SDI results to be sent via e-mail.