Authentication Types

DiveLine supports five different user authentication types so that you can select the best type for your network environment. Options include: Own, System, Web Server, OIDC, or LDAP. A short description of the selected type displays when you position the pointer over the type in Workbench.

Most often the DiveLine server is installed with default values in order to quickly verify that the clients, including Workbench, are functioning. If you decide to use a different authentication scheme, work needs to be done on the server using third party tools to configure the server appropriately for DiveLine. You can then use Workbench to change the authentication. You set the DiveLine Authentication Type in the Security section of the Server Settings > General tab (Tools > Server Settings > General > Security). After the server authentication type is set, it is rarely changed. If you do change the type, Workbench displays a confirmation dialog box.

NOTE: Details on using third-party tools to adjust the DiveLine server for different authentication schemes can be found in the installation guide. See the Windows 7.0 Installation and Operation Guides or Linux 7.0 Installation and Operation Guides.

You can override the DiveLine authentication type for individual users. Each user account has an option, which is available on the Users > Security/Licensing tab, to specify the authentication type for that user that takes precedence over the server authentication type. This override is useful when testing. For example, if DiveLine uses LDAP authentication, but you do not have authority to add LDAP users, you can create test users that use Own authentication.

DiveLine supports the following 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 Closedchoices you can set for the password policy. This configuration is important in encouraging your users to create strong passwords.

    OWN Password Policy

  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.

NOTE: Refer to the installation guides for tips on configuring your server for System authentication. See the Windows 7.0 Installation and Operation Guides or Linux 7.0 Installation and Operation Guides.

To use System authentication for DiveLine:

  1. Select ClosedSystem 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.

    SYSTEM Authentication

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.0 Installation and Operation Guides or Linux 7.0 Installation and Operation Guides) for tips on configuring your server for Web Server authentication or review this tech note: DLCGI Advanced Uses.

When using an external entity for authentication, typically SSO via dlcgi.exe, the DivePort client is configured to send unauthenticated visitors to a web-auth-start-url which is expected to redirect them back to DivePort with a one-time authentication token if that other service successfully authenticated them.

This runs into a snag when supporting some users who are not using single-sign-on. For instance, DI support personnel trying to login to a hosted site which is configured to use SSO for customer users. The experience is that the DI user is redirected to a URL which is likely not available to them outside the customer network, and thus they cannot login to DivePort.

Either of the following URLs will skip the CGI-authentication redirect:

https://<server>/<portal>/login

https://<server>/<portal>/#login=true

This brings the user directly to the DivePort logon dialog, where they can authenticate. This assumes the user is configured on DiveLine with an authentication override of OWN. This is similar to how ProDiver operates in this mode—if an attempt to use the DLCGI URL fails, the normal ProDiver login box is presented.

DI has successfully integrated DivePort/DiveLine single sign-on with ADFS (Active Directory Federation Services). The required steps:

  • Proxy DivePort through Apache and have Tomcat only listen to localhost:8443
  • Create a Shibboleth protected directory on Apache that hosts dlcgi
  • Setup the correct redirection URL's in diveport.xml
  • Integrate with the ADFS

Contact Technical Support for more details.

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 ClosedDLCGI Settings (click the expand chevron) to display the input fields.

    Web Server Authentication

  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.0 Installation and Operation Guides or Linux 7.0 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 ClosedLDAP Settings (click the expand chevron) to display the input fields.

    LDAP settings

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

The LDAP URL defines the LDAP server, the username attribute, and the filter for searching the LDAP database. It has a general form (as defined by RFC 2255):

ldap://<server>:<port>/<dn>?<attribute>?<scope>?<filter>

where:

  • server is the hostname of the LDAP server.
  • port is the TCP port number to use to connect to LDAP; if it is not specified, 389 is used by default.
  • dn is the base Distinguished Name used to login and start the search for the user.
  • attribute is used to match the user name given to DiveLine. If there are multiple attributes specified, only the first one is used. If no attributes are specified, it defaults to uid. In addition, DiveLine can match an attribute and return a different attribute.
  • ClosedAn alternate attribute example
  • scope is the scope of the search, and should be either “one” to search the children of the given base, or “sub” to search all descendants of the given base. Sub is recommended.
  • filter is a string representation of the filter to apply in the search. It is appended to the username search using an AND condition: (&(user=attr)(filter)). This is optional.

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.

Starting in Workbench 7.0(45), you can define multiple LDAPs for DiveLine and then set users to authenticate against a particular server. There is no CLI or GUI way to modify the additional LDAP configurations yet, but you can manually add values to the main block of atlcfg.cfg using this template:

other_ldaps = {

{

name="identifier",

ldap_url="...",

ldap_bind_dn="....",

ldap_bind_password="....",

ldap_tls="....",

},

. . .

}

The basic LDAP configuration attributes can be repeated in this array, with a different name field for each LDAP server that needs to be supported. Then the global auth_scheme or per-user auth_override settings can be set to LDAP:<name> instead of just LDAP to get the named entry from the other list. For example: LDAP:identifier

Starting with version 7.0(51), when multiple LDAP servers are defined in atlcfg.cfg, Workbench can retrieve them for maintenance purposes, as well as presenting them in the authentication pulldown, for selection as the global or per user setting. Click on Edit Other LDAP Servers to edit the list of other LDAP servers. Any LDAP servers added this way appear in the authentication pulldown as LDAP:<LDAP Name>.

To implement SSO (Single Sign-On) for LDAP on a Linux-based DiveLine server, you can configure a Windows server/VM with IIS running dlcgi.exe, the standard for Web Authentication. Then, configure the dlcgi.exe to refer to the Linux DiveLine as the target to forward authentication information to.

There is no automatic integration with LDAP for authorization of groups. However, it is possible to implement a system to pull data from LDAP and then use Integrator and the dicfg.exe utility to update the DiveLine configuration. This could be scheduled on a nightly basis.

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.