Authentication Types

Own authentication maintains user information entirely within Workbench (or Help Desk). You create users and passwords and assign security and licensing levels (see Managing Users and Licensing Levels).

With Own authentication, it is not necessary to create operating system user accounts because user accounts are maintained entirely within DiveLine through Workbench. When creating users in Workbench for use with Own authentication, a password is required; a blank password is not allowed. All user passwords are hashed within the DiveLine using the scrypt algorithm.

To use Own authentication:

1. Select Own from the Authentication Type list.

   A Password Policy section appears.

2. Expand the Password Policy section (click the expand chevron) to display the choices you can set for the password policy. This configuration is important in encouraging your users to create strong passwords.

   

3. Select the requirements and specify the limits.

4. Save the tab.

NOTE: The DiveLine server-level password settings interact with settings on individual user accounts. In one case, the server setting takes precedence and in another case, the user account setting takes precedence.

• If you set the DiveLine Password expires after X days option, users can change an expired password regardless of the User cannot change password setting in their user account.
• You can exempt an individual user from mandatory password expiration, set at the server level, by setting the Password never expires option in their user account (see Managing Users).

See also Command Line Utility dicfg.exe.

System authentication uses the DiveLine server’s UNIX operating system user account credentials for DiveLine authentication. This authentication type is available only on supported UNIX platforms. This is a convenient way to handle password authentication without maintaining a separate password list. However, you do need to define your users within Workbench (see Managing Users and Command Line Utility dicfg.exe). The user names assigned in the Workbench user account must exactly match the user names in the server’s operating system user account.

For the System authentication method, you do not assign passwords in Workbench. Any password specified in Workbench will be ignored.

To use System authentication for DiveLine:

1. Select System from the Authentication Type list.

2. Save the tab.

   There are no additional settings in Workbench for System authentication, but be sure to define users in Workbench or Help Desk.

   

NOTE: Starting with Workbench 7.1(13), you can use System Authentication and maintain passwords in DiveLine. This supports Two-Factor authentication configured on virtual machines hosted on the Diver Cloud platform. Users of DI web applications are required to enter their DiveLine username and password plus a TOTP 6-digit-PIN.

Web Server authentication takes advantage of a user and password list maintained by a Web Server. DiveLine includes a special script to communicate with the Web Server.

CGI (Common Gateway Interface) programs are supported on Web Servers such as Microsoft Internet Information Server (IIS) and Apache HTTP Server. Web Servers can respond to web requests from the local file system, or they can run local programs or scripts and return the output of those programs. DLCGI (DiveLine CGI) is such a program, which is designed to allow the use of a Web Server to authenticate users and streamline maintenance of client start pages. The program allows users to log in and authenticate to the Web Server, and have that logon forwarded to DiveLine. DiveLine can then take advantage of the users configured on the Web Server, including Windows Domain users, for authentication.

The result is a single logon at the Web Server (also known as single sign-on or SSO) and the ability to maintain passwords outside of DiveLine. However, you do need to define your users within Workbench (see Managing Users and the Command Line Utility dicfg.exe), and the user names assigned in the Workbench user accounts must exactly match the user names on the Web Server. Web Server authentication allows single logon access through ProDiver if you use a Windows Domain or if you launch ProDiver from a DivePort website using a dlk file.

In order to select Web Server authentication, the Web Server must be configured to use the dlcgi.exe. There are additional steps for DivePort as well. Supported Web Servers include Microsoft's Internet Information Services (IIS) and Apache Software Foundation's Apache HTTP Server. For example:

• IIS on Windows 10 / Server 2016
• IIS on Windows 8 / Server 2012
• Apache Web Server

NOTE: Contact Technical Support for assistance configuring your Web Server and tailoring DLCGI for your environment. You can also refer to the installation guides (see the Windows 7.1 Installation and Operation Guides or Linux 7.1 Installation and Operation Guides) for tips on configuring your server for Web Server authentication or review this tech note: DLCGI Advanced Uses.

After the web server and DLCGI are configured, you can proceed to use Workbench to set the DiveLine authentication.

1. Select Web Server from the Authentication Type list.

2. Expand the DLCGI Settings (click the expand chevron) to display the input fields.

   

3. In the Authentication URL (DLCGI) text box, enter the URL to the DLCGI executable on the Web server where users authenticate. An example of a valid URL is:

   http://abccorp/diveline/cgi-bin/dlcgi.exe

   where abccorp is replaced with the name of your web server.

   NOTE: Use HTTP Secure (https) if iOS devices (running 11.2.1 or later) are connecting to any DivePort sites on this server.

4. Enter the Web Server IP address of the computer on which the Web Server is installed and configured.
5. Save the tab.

See also Configuring Single Sign-on.

DiveLine supports use of the Lightweight Directory Access Protocol (LDAP). That is, DiveLine can authenticate users against an LDAP server running simple authentication. When DiveLine uses LDAP authentication, each time a user attempts to log in, DiveLine will:

• Request credentials

• Connect to an LDAP directory server

• Perform a search for the given user

• Authenticate that user with the given password

If authentication succeeds, the username attribute specified is passed back to DiveLine. That user then has access based on his or her account in Workbench. Note that you need to define your users within Workbench (see Managing Users and Command Line Utility dicfg.exe), and that the user names specified in the Workbench user accounts must match the user names in the LDAP exactly.

The key to DiveLine’s ability to make use of LDAP servers is the attributes defined using Workbench and saved in the atlcfg.cfg file. These attributes determine whether LDAP is supported, how a user’s credentials are matched against the directory, and the scope of a search that an application conducts in the LDAP tree.

LDAP authentication is supported in DiveLine running on:

• All Windows platforms
• Linux

The Microsoft directory services database that supports LDAP is Active Directory (AD). (Documentation is available from Microsoft.) LDAP authentication has been tested against both Microsoft Active Directory and OpenLDAP directories. On supported Linux platforms, the OpenLDAP libraries must be installed on the server in order for authentication to work.

NOTE: When configuring DiveLine LDAP authentication, the database schema must be known. However, on Windows, if it is unknown, the LDAP Data Interchange Format (LDIF) utility can be used to provide the necessary information.

There are three steps to configuring DiveLine to use LDAP authentication:

1. Obtaining LDAP information—consult with your LDAP administrator or call Technical Support for assistance:

   • Server name or IP address
   • Port number
   • Administrator account
   • Schema (from LDIF file)
   • Distinguished Name (DN)
   • User attribute to map to the DiveLine user name
2. Exporting the LDAP database listing—consult with your LDAP administrator or call Technical Support for assistance.
3. Configuring LDAP in Workbench—(see the following section).

NOTE: Refer to the installation guides (see the Windows 7.1 Installation and Operation Guides or Linux 7.1 Installation and Operation Guides) for details on steps 1 and 2, and tips on configuring your server for LDAP authentication.

Configuring LDAP in Workbench

To configure DiveLine to use LDAP in Workbench:

1. Choose LDAP from the Authentication Type list.

2. Expand the LDAP Settings (click the expand chevron) to display the input fields.

   

3. Provide the LDAP URL, Distinguished Name and Password for the LDAP administrator.
4. Save the tab.

The LDAP Bind Name has the form as in this example:

ldap_bind_dn="cn=alice,cn=Users,dc=test,dc=dimins,dc=com"

NOTE: When using LDAP authentication, a URL starting with ldaps:// may be specified to cause DiveLine to negotiate a secure connection before sending any passwords to the LDAP server. LDAPS (LDAP over TLS) is a good option when DiveLine is on one server and the authentication server is remote.

DiveLine supports use of the OpenID Connect (OIDC) authentication scheme for connections. OpenID Connect allows you to specify a third party provider to redirect to for user authentication. Issuers can be anything from a Microsoft Azure site to Google to Facebook. When you configure an OIDC provider in DiveLine, users can connect to that DiveLine through the provider's website. The process works as follows:

1. A user attempts to log onto their DiveLine user account.

2. DiveLine detects that the user should connect through OIDC.

3. The user is redirected to the OIDC identity provider's website.

4. The user logs onto the OIDC identity provider's website.

5. A verification token is sent to DiveLine and DiveLine gives access to the user.

This process ensures that DiveLine never handles a password. Instead, it sends the username to the identity provider, which then verifies the password. The user names assigned in the Workbench user accounts must exactly match the user names for the identity providers. Setting up OIDC requires configuring OIDC identity providers. This can be done either in the atlcfg.cfg file or through the interface in Workbench server settings.

NOTE: If a user's browser allows cookies, it is possible for the third party to retain their login credentials and does not always prompt them to re-enter their user information.

Configuring OIDC identity providers in Workbench

1. Expand the OpenID Connect Settings (click the expand chevron).

   

2. Click Edit OIDC Identity Providers.

   The Edit OIDC Providers window opens.

   

   The available columns are:

   • Name—A user-provided name for the OIDC identity provider.

   • Issuer—An OpenID Connect metadata URL or alternatively a URL that is supplied by the identity provider.

   • ClientID—A unique token supplied by the identity provider.

   • Drop Domain—If selected, any username formatted as [email protected] has the @domain.com portion removed before looking for a matching user in the DiveLine user list. For example, if a username is [email protected], only test is sent to the issuer; @company.com is removed.

   • Domains—Specifies which domains are used with the given Issuer and ClientID combination. Domains are generally only specified if there are multiple OIDC identity providers.

   • Advanced—Opens the OIDC Advanced Options window, where you can set the following attributes:

     • Username Claims—Certain Identity Providers send authorization responses with a name and value pair containing a username. This field defines names that might contain a DiveLine username as a value. This field accepts a comma-separated list for multiple potential names. This field accepts array notation. For example, given an array of usernames named users, providing users[0] returns the first element in the users array.

     • Scopes—Defines a comma-separated list of values that, when sent to an Identity Provider, determines what, if any, additional information needs to be sent back to assist in authorization.

     • Client Secret—This feature is specific to OIDC implementations that use Google as an Identity Provider. Stores a unique string of information only shared by the Identity Provider and DiveLine.

     • Discovery Endpoint—Stores the Identity Provider's discovery URI.

     • Authorization Endpoint—Stores the Identity Provider's authorization URI.

     • Token Endpoint—Stores the Identity Provider's token URI.

     • JWKS URI—Stores the Identity Provider's JWKS URI.

     • Web app response mode—As of 7.1(30), stores the mode used when returning the OIDC response and parameters. The only available value is currently query.

     • Metadata URI—Stores the Identity Provider's metadata URI.

3. When you are done adding identity providers, click OK.

4. At the top of the Security section, click the Authentication Type menu.

5. Each identity provider you created populates the Authentication Type menu in the format OIDC:[Identity Provider Name].

   

DiveLine supports two-factor systems that can operate using a single password. For instance, some systems have you type in a fixed password plus whatever is on a dongle. This can be used with System or Web Server authentication. With Linux systems using System authentication, the vendor can provide a PAM (Pluggable Authentication Module) security module. DiveLine configurations depend on the two-factor system being used and that system's capabilities to integrate into applications that are not aware of it.

Workbench 7.1(13) introduced 2FA Two-Factor Authentication via TOTP (time-based one-time passwords—Google Authenticator) for the Diver Cloud platform only. Azure Active Directory using SAML Security Assertion Markup Language is also supported, but also only in the DI cloud environment and only for DI web applications. Proper support for MFA or SAML/OpenAuth for Azure Active Directory (AAD) for the use of on-premise customers is an area of active development.