Keeper Connection Manager supports multiple authentication mechanisms which can be enabled through installing additional packages.

Authentication Methods

Multi-Factor Authentication

If you wish to enable multi-factor authentication in front of Keeper Connection Manager, you may do so with Duo or TOTP.

Overview

Keeper Connection Manager can be configured to authenticate users with any SAML 2.0 compatible identity provider. Users can be forced to login with SAML, or you can make SAML an optional login link from the login page as shown below.

Auto Docker Install Method

Run the reconfigure command listed below and press enter to accept all the pre-populated selections until you get to the SAML prompt.

Retreive your IdP Metadata

Instructions for setting up your identity provider and retrieving the XML metadata are found in the guides blow. Any SAML 2.0 identity provider is compatible.

Complete the Prompts

• Enter your SAML IdP URL.

• When asked about signed requests, if unsure, select no.

• Enter your SAML entity ID, and then the group attribute (this must match to your IdP's group attribute).

• Next, you're asked if you want SAML as the default login process. If you want SAML login to be an option (link) on the login page, select no. If you want SAML as the only possible method of authentication, select yes.

SSO Configuration is complete!

Docker Compose Install Method

If you installed Keeper Connection Manager using the Docker Compose Install method, this does not come preconfigured with SAML support. The instructions for activating SAML are below:

(1) On the local instance, stop the containers.

(2) Edit the docker-compose file

Using the custom docker method requires modification of docker-compose.yml file to add SAML support. As root, edit your docker-compose.yml file and find the "guacamole" section.

Create a volume mount for sharing the metadata.xml file with the container. If you already have a shared volume for this purpose, you can use that one. There is also another section needed which needs SAML environmental variables. A sample file is listed below.

Notes:

• Replace "/var/lib/guac_home" with the local path to your volume

• Replace "https://demo.lurey.com" in 2 spots with your Keeper Connection Manager login URL

• Only use this SAML group attribute if you're using Azure. Other identity providers will use a different Group attribute ID.

• If you want ALL users to login with SAML, then remove the ADDITIONAL_GUACAMOLE_PROPERTIES line. As written, it will give users the choice of password or SAML login.

(3) Create the local folder volume if it doesn't exist yet

(4) Copy the metadata.xml file from your local computer (downloaded from step 8 above) into the location of the volume mount referenced in the guacamole section of the docker-compose file.

(5) Restart the containers

Configuration is complete.

Complete

Once you have activated the SAML module, there will be a new "Sign in with SAML" link on the login screen of the application as seen below:

Azure Configuration

The first step regardless of installation method is to configure your SAML 2.0 identity provider using Microsoft Azure.

(1) In Azure, go to Enterprise Applications and Create a new application.

(2) Give the Enterprise Application a name, and then select "non-gallery" application.

Okta Configuration

The first step regardless of installation method is to configure your SAML 2.0 identity provider using Okta.

(1) In Okta, go to Admin > Applications > Create App Integration and select SAML 2.0. Click Next.

(2) Give the Enterprise Application a name and upload the logo file linked below then click Next.

The image logo is here:

(3) Configure the SAML Settings

The SAML configuration should match the format as seen below:

• Replace demo3.lurey.com with the URL of your Keeper Connection Manager domain.

• Ensure the full path appears, e.g. https://DOMAIN/api/ext/saml/callback

• For the Audience URI, use the path to the Login screen (remove the trailing slash). For example, https://demo3.lurey.com

Scroll down to the Group Attribute Statements. To send the group attribute, set the name to "groups", and the name format to "Basic". If you would like ALL groups assigned to the user to be sent to Keeper Connection Manager, select the "Matches regex" with a value of ".*"

Click Next.

(4) In the Feedback section, make the selections as appears below.

(5) Assign users and/or groups to the Keeper Connection Manager application, as you would normally do with any SAML connected app.

(6) Download the Okta Metadata file and save to your local machine as metadata.xml

The location of the metadata file depends on your version of the Okta interface. In this example there is a link called "Identity Provider metadata" on the application page. There may also be a text box that contains the metadata which you can copy and paste into a local file on your computer.

The metadata XML file could also be linked in the Sign On tab > SAML Signing Certificate section under "Actions".

Save the resulting metadata.xml file by selecting "Save page as..." in your browser.

The Okta side of the setup is complete. Note if you change anything, you need to re-download a new metadata.xml file. Transfer this metadata.xml file to your KCM server machine.

OneLogin Configuration

The first step regardless of installation method is to configure your SAML 2.0 identity provider.

You must have OneLogin developer account.

Configure OneLogin

1. Log in to the Dashboard, and click Administration. Then Applications > Add App.

2. Search for SAML, and select SAML Test Connector (IdP).

3. When prompted, change the Display Name of your app. Enter an application name and description. You can also upload a Keeper Connection Manager logo. Click save.

4. Go to the Configuration tab, Update 3 fields: Recipient, ACS (Consumer) URL Validator, and ACS (Consumer) URL with your KCM server URL and /api/ext/saml/callback on the end as shown below.

1. Click on the More Actions dropped-down menu. Select SAML Metadata to download and save the .XML file.

2. Under the Users tab on the top, find the users that need to log in using SSO, click into them and on the applications tab on the left, add the new SAML application to them.

PingIdentity Configuration

1. Login as an Administrator for PingIdentity. From the PingIdentity menu, click Applications > Add Application

Keeper Connection Manager provides support for Duo as a second authentication factor, automatically verifying user identity with Duo after the user is initially authenticated. This integration utilizes the V4.

Duo Setup

From the DUO Security Admin portal:

• Select "Protect an Application"

Keeper Connection Manager provides support for TOTP as a second authentication factor, verifying the identities of enrolled users using authentication codes generated with the TOTP standard.

Docker Environmental Variables

To enable TOTP add the following lines to the "environment" section of the "guacamole" service in the docker-compose.yml file. Only the EXTENSIONS: totp line is required, the rest are optional.

For example:

Auto Docker or Docker Compose

When using the docker version of KCM, you can list the multiple LDAP servers in your docker-compose.yml file using the environment variable LDAP_SERVERS in the environment section of the guacamole service, as shown below:

Keeper Connection Manager provides support for OpenID Connect for authentication.

Docker Environmental Variables

The image keeper/guacamole can be modified to support OpenID using environmental variables. See the OPENID_* variables defined in the documentation.

Multiple Hostnames/Configurations for SSL Termination

The keeper/guacamole-ssl-nginx image is specifically intended to provide SSL termination for the Guacamole image provided by Keeper for KCM. Historically, this image supported only a single hostname and configuration:

    ssl:
        image: keeper/guacamole-ssl-nginx:2
        restart: unless-stopped
        ports:
            - "80:80"
            - "443:443"
        environment:
            SELF_SIGNED: "Y"
            ACCEPT_EULA: "Y"
            CONTENT_TYPE_OPTIONS: "Y"
            CONTENT_SECURITY_POLICY: "Y"
            GUACAMOLE_HOSTNAME: "guacamole"
            SSL_HOSTNAME: "example.net"

As of KCM 2.12.0, the keeper/guacamole-ssl-nginx image can be used with multiple hostnames and configurations via a special SERVERS environment variable that accepts YAML (or JSON).

The SERVERS variable must contain a YAML (or JSON) array of objects, where each object contains the name/value pairs of environment variables that should apply to that additional configuration. Any variable that is not specified is inherited from the top-level environment. For example:

The above configuration would result in an NGINX instance that handles both example.net and *.example.net hostnames equivalently. Both will get their own self-signed certificates because SELF_SIGNED is set to Y.

A more complex example:

The above configuration would result in an NGINX instance that generates and uses a self-signed certificate for *.example.net, but obtains a certificate for example.net from Let’s Encrypt.

IMPORTANT: The value of SERVERS must be a string, hence the | symbol within the above examples. If this symbol is omitted, then the YAML that follows is parsed as an object, and validation of the docker-compose.yml will fail, as all Docker environment variables must be strings.

NOTE: NGINX will use the first server as the default for any request that does not match any configured hostname. If any server declared in SERVERS should have this behavior, it must be the first server listed.

Go to your Oracle Admin Console and navigate to the Identity Domains Overview page, then select Applications as depicted above.

Click on Add Application.

Select SAML as the application type.

Apply the appropriate settings to the Application Information as needed for your security posture. Click on Edit SSO Configuration. Download the Metadata and rename the file to metadata.xml. Set the Entity ID to the URL of your Connection Manager server. For example: https://kcm.somedomain.com. For the Assertion Consumer URL, add /api/ext/saml/callback to the end of the domain URL. For example: https://kcm.somedomain.com/api/ext/saml/callback. Next, set the Name ID Format to Email Address and the Name ID Value to Primary Email. Leave the Signed SSO setting as Assertion. Uncheck the box to Include Signing Certificate in Signature, and leave the Signature Hashing Algorithm as SHA-256.

Assign attributes for email as listed above mapped to the value User Name. Add another attribute for groups with the settings of Type Value Group Membership and a Condition of All groups.

Assign users and groups as appropriate to your SAML application. You'll need to assign at least one user for testing purposes.

Connection Manager Server Configuration

Upload the metadata.xml file to your KCM server and move it into the directory /etc/kcm-setup.

Run the reconfigure command after production hours on your Connection Manager server.

Say Y to the option when presented to setup SAML support.

Select 1 for Local Metadata file. Then input the path of your metadata file as /etc/kcm-setup/metadata.xml and press enter. Answer N to Does your SAML IDP require signed requests? Input your SAML entity ID as the URL of your Connection Manager instance. For example: https://kcm.somedomain.com. Then enter groups as the SAML group attribute.

Choose which setting best applies to your security posture with regard to the default authentication method. If you want Just-In-Time provisioning of users, then answer Y to Would you like user accounts to be automatically created for each successful login?

Click the SAML link to authenticate to the main sign on page.

Your user email address should display in the top right corner after authenticating.

If multiple authentication methods are installed, Keeper Connection Manager will poll each method as it attempts to authenticate users, and will retrieve connection data from each method once a user has successfully authenticated. This behavior is designed to allow authentication methods to work together, and can be leveraged to authenticate Keeper Connection Manager users against LDAP while storing the connection data for those users within MySQL, PostgreSQL, or SQL Server.

Keeper Connection Manager's definition of identity

When reading data from multiple authentication methods, Keeper compares the unique identifiers of users (usernames) and groups to determine identity. This means that user accounts from different authentication systems will be automatically combined by Keeper upon successful authentication as long as those user accounts have the same username, and group memberships will take effect across authentication systems so long as the unique names of those groups match.

If both LDAP and a database authentication method have been configured, Keeper will automatically attempt to authenticate against both systems whenever a user attempts to log in. The LDAP account will be considered equivalent to the database user if the username is identical, and that user will have access to any data associated with them via the database, as well as any visible objects within the LDAP directory. If that user has permission to query their group memberships within LDAP, and Keeper then the user's group membership will also be retrieved upon authentication, and the user will have access to any data associated with those groups via the database.

Administering LDAP users within Keeper Connection Manager

Rather than having to manually look up users or groups within the LDAP directory, and then manually create those same users and groups within Keeper Connection Manager, it is possible to set up administrative user accounts which can already see and manage available LDAP objects. This streamlines the administrative process, reducing the number of users which must be manually created to one.

To see LDAP objects within Keeper Connection Manager's administrative interface, one of the following tasks must be performed:

1. An administrative user within the Keeper Connection Manager database, such as the default “guacadmin” user, must be manually created within LDAP with the same username and with sufficient privileges to query all Guacamole users and groups defined within LDAP.

2. An administrative user must be manually created within Keeper Connection Manager having the same username as an LDAP user with sufficient privileges to query all Guacamole users and groups defined within LDAP.

Because a Keeper Connection Manager user created as defined above would have access to LDAP users and groups, database users and groups, and database connections, all of this data will be unified within the same administrative interface within Keeper Connection Manager. The user will be able to grant LDAP users and groups access to connections within the database to just as they would if only the database were in use.

Google Workspace Configuration

The first step regardless of installation method is to configure your SAML 2.0 identity provider using Google Workspace.

(1) Login to Google Workspace

Visit the Apps > Web and Mobile Apps screen.

(2) Select "Add App" and select "Add Custom SAML App".

In an environment where KCM users may be automatically created from an SSO system, such as SAML or OpenID or PIV/CAC, administrators may wish to more tightly control whether those users are allows to use KCM. To facilitate this, KCM provides administrators an approve/deny workflow to decide whether an individual user should be allowed to authenticate with KCM using that SSO method.

Configuring the KCM user creation workflow

To require approval for users signing in with a particular authentication method, use the require-account-approval property (or, for Docker, the REQUIRE_ACCOUNT_APPROVAL environment variable). This property accepts a comma-separated list of the names of all authentication methods that should require administrator approval. KCM supports the following authentication types:

User Management in Keeper Connection Manager

Keeper Connection Manager offers flexible user management capabilities that allow administrators to control access, apply account restrictions, assign permissions, and configure connection visibility for individual users or groups.

Defining the guacConfigGroup object class

When connection data is stored within your LDAP directory, each connection is represented by a special type of LDAP group, and permissions related to Keeper Connection Manager's connections can be managed directly with LDAP based on user membership of these groups. Doing this requires schema modifications which add a new object class called guacConfigGroup.

An LDIF file defining the schema changes in a manner compatible with OpenLDAP is provided by the kcm-guacamole-auth-ldap

Keeper Connection Manager provides support for LDAP authentication.

Docker Environmental Variables

The image keeper/guacamole can be modified to support LDAP using environmental variables. See the LDAP_* variables defined in the .

Keeper Connection Manager can be configured to require SSL/TLS client authentication.

Client Certificate Overview

To implement device-based access security with Keeper Connection Manager, this can be accomplished using NGINX client certificates. A client certificate is installed into the web browser of your user's approved devices, and the server will only accept communication from a device with the client certificate installed.

The steps to activate this advanced level of protection is described in the steps below.

(1) Create a Certificate Authority (CA) Key

KCM allows authentication with the web application using the DoD's Common Access Cards (CAC), as well as with any smart card supported by the browser for SSL client auth such as Personal Identity Verification (PIV).

This support depends on an SSL termination instance providing SSL/TLS authentication, a capability that was added to KCM version 2.12.0.

A typical configuration for PIV/CAC would be the following:

1. An SSL termination instance configured with : one for normal access (such as kcm.example.net) and another just for handling , which should ideally be a wildcard domain (such as *.login.kcm.example.net). The SSL client auth configuration would include the certificate of the CA providing the PIV/CAC cards.

2. PIV/CAC support installed and configured to authenticate users against *.login.kcm.example.net and redirect them back to kcm.example.net once ready.

3. Database backend configured to automatically create user accounts for users coming from SSO.

4. to require approval for users that SSO from PIV/CAC.

Configuration Options for PIV/CAC

Support for PIV/CAC is configured using Keeper's new support for SSL/TLS client authentication. This support is provided by the “guacamole-auth-sso-ssl” extension, which we package as kcm-guacamole-auth-sso-ssl. Setting any SSL_* variable will implicitly include the kcm-guacamole-auth-sso-ssl package.

The following options will need to be set in the Docker container definition (or in guacamole.properties for linux distributions):

The following options are also available, though it would be unusual to need to set them:

SSL (NGINX) Configuration Options for PIV/CAC

Authenticating with PIV/CAC (or any smart card) via the browser is using . This capability was further enhanced for PIV/CAC by adding convenient configuration options for testing whether certificates have been revoked via OCSP or a CRL. For reference, the following are all options related to SSL/TLS client authentication currently supported by the Docker image:

Example PIV/CAC Configuration

The example docker-compose.yml below uses the following placeholders:

In practice, these values will vary, as will whether the user chooses to use MySQL or PostgreSQL. The example below was written using PostgreSQL.

Configuring the KCM user creation workflow

Prior to configuring the user workflow, make sure to set the REQUIRE_ACCOUNT_APPROVAL key to the appropriate authentication method.

For PIV/CAC, you would set it to ssl:

Once you have successfully configured, there will be a new "Use Certificate or Smart Card" link on the login screen of the application as seen below:

For additional details on user creation workflow, visit this .

Installing CA Authority

For each end-user client device that will need access to Keeper Connection Manager, you may need to install the internal CA as a trusted authority into the user's browser. The installation of CA trusted authority varies by platform.