1 of 62

SSO Connect Cloud

Keeper SSO Connect Cloud

Enhance and Extend Your SSO and Passwordless Solution

Keeper SSO Connect is a Cloud-based SAML 2.0 service that seamlessly and quickly integrates with your existing Single Sign-On and Passwordless solution - enhancing and extending it with zero-knowledge password management and encryption. Keeper supports all popular SSO IdP platforms such as Microsoft Entra ID / Azure, Okta, Google Workspace, Centrify, Duo, OneLogin, Ping Identity, JumpCloud and many more.

Product Page

Overview

High level overview of Keeper SSO Connect™ Cloud

End-to-End Password Protection Across Your Data Environment

Simply by authenticating through your existing IdP, your employees gain access to all of the capabilities of the top-rated Keeper password management platform, including:

Secure digital vault that can be accessed from any device, running any OS

F5

How to configure Keeper SSO Connect Cloud with F5 BIG-IP APM for seamless and secure SAML 2.0 authentication.

Please complete the steps in the section first.

F5

RSA SecurID Access

How to configure Keeper SSO Connect Cloud with RSA SecurID Access for seamless and secure SAML 2.0 authentication.

Please complete the steps in the Admin Console Configuration section first.

Keeper Security is RSA SecurID Access Certified.

RSA SecurID Access integrates RSA Authentication Manager and their Cloud Authentication Service. In this setup Cloud Authentication Service can be used as an identity provider in conjunction with Keeper SSO Connect. Detailed documentation is provided on the RSA website via the links below.

RSA SecurID Access Overview

Keeper Password Manager Integration Guides

SecureAuth

How to configure Keeper SSO Connect Cloud with SecureAuth for seamless and secure SAML 2.0 authentication.

Please complete the steps in the section first.

SecureAuth can be configured using the same instructions in the section. Please follow that guide in order to set up the SecureAuth environment.

For reference, use the SecureAuth guide located here:

A few additional important items to note regarding SecureAuth:

Passwordless Providers

Passwordless configuration for SSO Connect Cloud

The previous section of Admin Console Configuration applies to every SAML 2.0 compatible passwordless provider. To help with configuration of common passwordless providers, we have added some helpful screens in this next section.

Veridium

How to configure Keeper SSO Connect Cloud with Veridium for Passwordless login to Keeper.

Please complete the steps in the Admin Console Configuration section first.

(1) Add a new service provider

From the Veridium interface, click on Add Service Provider.

(2) Download Keeper metadata

On the Keeper Admin Console, export the SAML Metadata file.

Go to View -> Export Metadata

(3) Upload Metadata to Veridium

In the service provider name box enter “Keeper”, upload the metadata file from Keeper and select “Email” as the NameID format.

(4) Map Attributes

Map the firstname, lastname and mail attributes and click “Save”.

Integration is now complete. A video demo of the Veridium login flow can be seen below:

Device Approvals

SSO Cloud device approval system

Overview

Device Approvals are a required component of the SSO Connect Cloud platform. Approvals can be performed by users, admins, or automatically using the Keeper Automator service.

For customers who authenticate with Keeper SSO Connect Cloud, device approval performs a key transfer, in which the user's encrypted data key is delivered to the device, which is then decrypted locally using their elliptic curve private key.

Keeper Push

Keeper Push is a method of SSO device approval using existing devices

Overview

Users can approve their additional devices by using a previously approved device. For example, if you are logged into your web vault on your computer already, and logging into your phone app for the first time, you will get a device approval prompt on your web vault with the mobile device's information which you can approve or deny. Device Approvals perform an encryption key exchange that allow a user on a new device to decrypt their vault.

Keeper Push Method

Keeper Push is a method of approval that the user handles for themselves. Selecting "Keeper Push" will send a notification to the user's approved devices. For mobile and desktop apps, the push will show as a pop-up, and the user can simply accept the device approval.

Here's an example of Keeper Push approval using mobile as the approver device:

Steps to Using Keeper Push

(1) Select Keeper Push

(2) User waits for the push approval to appear on the device in which they are already logged in.

(3) User must be already logged into a different, previously approved device in order to receive the notification.

Admin Approval

Admins can approve end-user SSO Cloud devices

Admin Approval Method via Admin Console

Selecting "Admin Approval" will send the request to the Keeper Administrator with the "Approve Devices" permission. The Admin can perform the approval through the Admin Console "Approval Queue" screen or by being logged into the Admin Console at the time of the request.

(1) User selects "Admin Approval"

(2) User waits for approval or comes back later

Keeper Automator Service

Automatic device approval service for SSO Connect Cloud environments

Overview

The Keeper Automator is a self-hosted service which performs cryptographic operations including device approvals, team approvals and team user assignments.

Once Automator is running, users can seamlessly access Keeper on a new (not previously approved) device after a successful authentication with your identity provider, without any further approval steps. Without the Automator service, users and admins can still perform manual device approvals through Push Approval methods.

Keeper Automator is a lightweight service that can be deployed in your cloud or on-prem environment.

Version 17.0 Overview

Instructions for upgrading your Automator instance to v17.0

Overview

Version v17.0+ incorporated several new features:

Team Approvals (Team Creation)
Team User Approvals (Assigning Users to Teams)
All settings can be configured as environment variables
Support for simplified deployment
Support for simplified deployment
HSTS is enabled for improved HTTPS security
IP address filtering for device approval and team approval
Optional rate limiting for all APIs
Optional filtering by email domain
Optional binding to specific network IPs

Team User approvals

Teams and users who are provisioned through SCIM can be immediately processed by the Automator service (instead of waiting for the admin to login to the console).

To activate this new feature:

Update your Automator container or .zip file to the latest version
Use the automator edit command in Keeper Commander to instruct the service to perform device approvals and also perform Team User approvals:

Example:

With the skill enabled, automator is triggered to approve team users when the user logs into their vault

Team Approvals

When team creation is requested by the identity provider via SCIM messaging, the request is not fully processed until someone can generate an encryption key (to preserve Zero Knowledge). This is normally processed when an admin logs into the Keeper Admin Console.

When team approvals is activated on the Keeper Automator service, teams are now created automatically when any assigned user from the team logs in successfully to the Keeper Vault. Therefore, teams will not appear in the environment until at least one user from that team logs into their vault.

Teams will not appear in the environment until at least one user from that team logs into their vault.

All settings can be configured as environment variables

This makes configuration easier when installing Automator in Azure Containers or other Docker-like containers where access to the settings file is difficult.

In Docker, Azure Containers, or other environments that use the docker-compose.yml file, you can set environment variables in the docker compose file, for example:

After editing the docker-compose.yml file, you will need to rebuild the container if the environment variables have changed. Just restarting the container will not incorporate the changes.

Advanced Features

for all of the new and advanced features / settings for the Automator service.

Ingress Requirements

Ingres configuration for Keeper Automator

Keeper Automator can be deployed many different ways - on prem, cloud or serverless.

Data Flow Diagram

Troubleshooting

Common issues and troubleshooting for your Automator service

Unable to communicate with the Automator service

There are several reasons why Keeper Commander is unable to communicate with your Automator service:

Ensure that the automator service is open to Keeper’s IP addresses. The list of IPs that must be open are found at this Ingress Requirements page. We recommend also adding your own IP address so that you can troubleshoot the connection.
If you are using a custom SSL certificate, ensure that the SSL certificate is loaded. Check the Automator log files which will indicate if the certificate is loaded by the service restart. If the IP address is open to you, you can run a health check on the command line using curl, for example: curl https://automator.mycompany.com/health
Check that the subject name of the certificate matches the FQDN.
Check that your SSL certificate includes the CA intermediate certificate chain. This is the most common issue that causes a problem. Keeper will refuse to connect to Automator if the intermediate certificate chain is missing. You can do this using openssl like the following:

This command will clearly show you the number of certificates in the chain. If there's only a single cert, this means you did not load the full chain. To resolve this, see Step 4 of the step by step instructions page.

400 Error in Health Checks

This may occur if the healthcheck request URI does not match the SSL certificate domain. To allow the healthcheck to complete, you need to disable SNI checks on the service. This can be accomplished by setting the disable_sni_check=true in the Automator configuration or passing in the environmental variable DISABLE_SNI_CHECK with the value of "true".

Certificate Renewal

Keeper SSO Connect certificate renewal instructions

Keeper SSO Connect Certificate Renewal Process

It is critical to ensure that your IdP SAML Signing Certificates are renewed and activated. Typically, this occurs once per year.

If you receive the below error when logging into the Keeper vault, this usually indicates that the SAML Signing Certificate has expired.

"Sorry! There was an unexpected error logging you into Keeper via your company account. We are unable to parse the SAML Response from the IDP"

Logout Configuration

Configuration options for Single Logout (SLO) between Keeper and IdP

Different customers may have different desired behavior when a user clicks on "Logout" from their Keeper vault. There are two choices:

Option 1: Don't logout from IdP

Clicking "Logout" from the Keeper Vault will just close the vault but stay logged into the Identity Provider.
Logging into the Keeper Vault again will defer to the Identity Provider's login logic. For example, Okta has configurable Sign-On rules which allow you to prompt the user for their MFA code before entering the application. See your identity provider sign-on logic to determine the best experience for your users.

Option 2: Logout from IdP

Clicking "Logout" from the Keeper Vault will also logout the user from the Identity Provider.
This may create some frustration with users because they will also logout from any IdP-connected services.
Users would need to be directed to simply close the vault and not click "Logout" if they don't like this behavior.

How to Enable Single Logout (SLO)

If your identity provider has a "Single Logout" option, then you can turn this feature ON from the identity provider configuration screen. For example, Okta has a "Single Logout" checkbox and they require that the "Keeper SP Certificate" is uploaded. After changing this setting, you will need to export the metadata from the IdP and import it back into the Keeper SSO configuration screen.

How to Disable Single Logout (SLO)

If your identity provider has a "Single Logout" option, then you can turn this feature OFF from the identity provider configuration screen and upload the new metadata file into Keeper.
If the IdP does not have a configuration screen on their user interface, you can just manually edit the IdP metadata file (screenshot below). In a text editor or vim, remove the lines highlighted below that represent the SLO values. Then save the file and upload the metadata into the Keeper SSO configuration screen.

User Provisioning

Instructions on how to provision users with SSO Connect Cloud

Onboarding Users

There are several options for onboarding users who inside an SSO-provisioned node:

System Architecture

SSO Connect Cloud System Architecture

Migrate from OnPrem

How to migrate from Keeper SSO On-Prem to Cloud SSO

See the below instructions:

Graphic Assets

Keeper Password Manager graphic assets for IdP configuration

This page contains various graphic assets of Keeper icons and logos for use in your identity provider, if required.

Zip file with various sizes:

512x512 PNG Square Icon:

https://keeper-email-images.s3.amazonaws.com/common/512x512_icon.png

256x256 PNG Square Icon:

https://keeper-email-images.s3.amazonaws.com/common/256x256_icon.png

128x128 PNG Square Icon:

https://keeper-email-images.s3.amazonaws.com/common/128x128_icon.png

Keeper Logo - JPG white background:

Keeper Logo - PNG transparent background:

Keeper Logo - JPG White on black background:

Links & Resources

PingOne

How to configure Keeper SSO Connect Cloud with PingOne for seamless and secure SAML 2.0 authentication.

Please complete the steps in the Admin Console Configuration section first. Legacy Ping Identity users who are not on PingOne should view our Ping Identity documentation.

PingOne

From the PingOne console menu, select Applications > Application Catalog

Search "Keeper" and click on the "Keeper Password Manager - Cloud SSO" link to add the Keeper Password Manager application

Click Setup to proceed to the next step

Click "Continue to Next Step"

From the Keeper Admin Console, view the PingOne SSO Connect Cloud entry and click Export Metadata and save it in a safe location for future use. Also click Export SP Cert and save it in a safe location for future use.

From the PingOne Admin Console, click Select File next to "Upload Metadata" and browse to the saved metadata file from the Keeper Admin Console. This should populate the "ACS URL" and "Entity ID" fields with the proper datapoints.

Click on Choose File next to "Primary Verification Certificate" and browse to the saved .crt file from the Keeper Admin Console. Click on the checkbox next to "Encrypt Assertion" and then click Choose File next to "Encryption Certificate". Browse to the same saved .crt file from the Keeper Admin Console.

Validate the certificate and click "Continue to Next Step".

Enter the appropriate values associated with each attribute (see below image) and click Continue to Next Step

Modify the Name to appropriately match the Configuration Name of the SSO node from the Keeper Admin Console. Click Continue to Next Step

You may choose to add PingOne user groups to your application. Click Add next to the group or groups you would like to add and click Continue to Next Step.

PingOne users will have access to Keeper Password Manager by default. Assigning groups to Keeper Password Manager restricts access to only those groups.

Click Download next to "SAML Metadata" and save the .xml file to a safe location.

Click Finish to complete the application setup wizard.

On the Edit Configuration screen of the Keeper SSO Connect Cloud provisioning in the Keeper Admin Console, select PingOne as the IDP Type.

Upload the SAML Metadata file downloaded in the previous step into the Keeper SSO Connect interface by browsing to or dragging and dropping the file into the SAML Metadata section.

The PingOne Keeper SSO Connect Cloud™ entry will now show as Active.

Your PingOne Keeper SSO Connect Cloud™ setup is complete!

Move existing users/initial admin to SSO authentication

Users created in the root node (top level) will need to be migrated to the sub node that the SSO integration was configured on. If users remain in the root node, they will be prompted for the master password when accessing the vault and/or admin console.

An admin can not move themselves to the SSO enabled node. It requires another admin to perform this action.

After the user is moved to the SSO enabled node, they need to log into the Keeper vault initially by selecting the "Enterprise SSO" pull down and inputting in the Enterprise Domain configured on the SSO integration. The user may get prompted to confirm by entering in the master password.

Once the user has authenticated with SSO, they only need to use their email address moving forward to initiate SSO authentication.

They won't have to enter the Enterprise Domain. If typing in the email address and clicking Next does not route the user to the desired SSO, ensure that just-in-time provisioning is enabled in the Keeper SSO configuration and ensure that your email domain is reserved by Keeper. More information regarding routing and domain reservation .

Advanced Settings

Configuration settings and features on Automator

Overview

The settings in this document control the features and security of the Automator service.

Setting: `automator_debug`

Env Variable: AUTOMATOR_DEBUG

Description: This is an easier way to turn on/off debug logging in Automator.

Setting: `automator_config_key`

Env Variable: AUTOMATOR_CONFIG_KEY

Default: Empty

Description: Base64-url-encoded 256-bit AES key. This is normally only used as an environment variable. (since v3.1.0). This setting is required to load the encrypted configuration from the Keeper cloud if there is no shared /usr/mybin/config file storage between container instances.

Setting: `automator_host`

Env Variable: AUTOMATOR_HOST

Default: localhost

Description: The hostname or IP address where the Automator service is listening locally. If SSL is enabled (ssl_mode parameter), the automator_host value needs to match the SSL certificate subject name. The setting disable_sni_check can be set to false if the subject name does not match.

If the service is running on a machine with multiple network IPs, this setting will bind the Automator service to the specified IP.

If you encounter binding errors in the service startup, it is recommended to use the local network IP address in the host setting instead of localhost.

Setting: `automator_port`

Env Variable: AUTOMATOR_PORT

Default: 8089

Description: The port where the Automator listens. If running in Docker, use the default 8089.

Setting: `disable_sni_check`

Env Variable: DISABLE_SNI_CHECK

Default: false

Description: Disable the SNI check against the certificate subject name, if SSL is being used.

Setting: `email_domains`

Env Variable: EMAIL_DOMAINS

Default: null

Description: A comma-separated list of user email domains for which Automator will approve devices or teams. Example: "example.com, test.com, mydomain.com". This depends on the filter_by_email_domains setting to be enabled as well.

Setting: `filter_by_email_domains`

Env Variable: FILTER_BY_EMAIL_DOMAINS

Description: If true, Keeper will consult the email_domains list. If false, the email_domains list will be ignored.

Setting: `enabled`

Env Variable: N/A

Default: false

Description: This determines if Automator is enabled or disabled.

Setting: `enable_rate_limits`

Env Variable: ENABLE_RATE_LIMITS

Default: false

Description: If true, Automator will rate limit incoming calls per the following schedule:

approve_device: 100 calls/minute with bursts to 200

approve_teams_for_user: 100 calls/minute with bursts to 200

full_reset: 4 per minute, with bursts to 6

health: 4 per minute

initialize: 4 per minute, with bursts to 6

setup: 4 per minute, with bursts to 6

status: 5 per minute

Setting: `ip_allow` and `ip_deny`

Env Variable: IP_ALLOW and IP_DENY

Default: ""

Description: This restriction allows users to be eligible for automatic approval. Users accepted by the IP restriction filter still need to be approved in the usual way by Automator. Users denied by the IP restriction filter will not be automatically approved.

If "ip_allow" is empty, all IP addresses are allowed except those listed in the "ip_deny" list. If used, devices at IP addresses outside the allowed range are not approved by Automator. The values are a comma-separated list of single IP addresses or IP ranges. The "ip_allow" list is checked first, then the "ip_deny" list is checked.

Example 1: ip_allow=

ip_deny=

Example 2:

ip_allow=10.10.1.1-10.10.1.255, 172.58.31.3, 175.200.1.10-175.200.1.20

ip_deny=10.10.1.25

Setting: `name`

Env Variable: N/A

Default: Automator-1

Description: The name of the Automator. It should be unique inside an Enterprise. An automator can be referenced by its name or by its ID.

Setting: `persist_state`

Env Variable: N/A

Default: true

Description: If true, the Automator state will be preserved across shutdowns. Leave this on.

Setting: `skill`

Env Variable: N/A

Default: device_approval

Description: “device_approval” means device approval. “team_for_user_approval” means team approvals. An Automator can have multiple skills. “device_approval” is the default.

Setting: `ssl_certificate`

Env Variable: SSL_CERTIFICATE

Default: null

Description: A Base64-encoded string containing the contents of the PFX file used for the SSL certificate. For example, on UNIX base64 -i my-certificate.pfx will produce the required value.

Using this environment variable will override the ssl_certificate_filename setting.

Setting: `ssl_certificate_file_password`

Env Variable: SSL_CERTIFICATE_PASSWORD

Default: ""

Description: The password on the SSL file. If used, the key password should be empty, or should be the same. The library we use does not allow different passwords.

Setting: `ssl_certificate_key_password`

Env Variable: SSL_CERTIFICATE_KEY_PASSWORD

Default: ""

Description: The password on the private key inside the SSL file. This should be empty or the same as the file password.

Setting: `ssl_mode`

Env Variable: SSL_MODE

Default: certificate

Description: The method of communication on the Automator service. This can be: certificate, self_signed, or none. If none, the Automator server will use HTTP instead of HTTPS. This may be acceptable when Automator is hosted under a load balancer that decrypts SSL traffic.

Setting: `url`

Env Variable: N/A

Default: ""

Description: The URL where the Automator can be contacted.

CloudGate UNO

How to configure Keeper SSO Connect Cloud with CloudGate for seamless and secure SAML 2.0 authentication.

Please complete the steps in the Admin Console Configuration section first.

CloudGate SSO Configuration

(1) Log into the CloudGate Administrator console.

Click the Administration tile on the menu.

(2) Next, Select the Service Provider menu item and click Add Service Provider.

On the "Add Service Provider" page, search for Keeper in the search bar. Select and click the "Keeper SSO Connect Cloud" icon.

(3) Set the Display name at General Settings tab to “Keeper_SSO_Cloud_Connet” or whatever you prefer.

(4) Next, at the SSO Settings tab, you need the "Entity ID" and Other information that comes from the Keeper Admin Console.

Copy and Paste the Entity ID and Other information into the SSO Settings page in the CloudGate screen.

Your SSO ID can be found at the end of your SP Entity ID. Ex: https://keepersecurity.com/api/rest/sso/saml/3534758084794

(5) Click Add the Additional Attributes, and set Field Name to "Email" and the Value to "${MAIL_ADDRESS}". Now you can save the configuration.

(Optional) Enable Single Logout

If you would like to enable the Single Logout feature in CloudGate, go to the SSO Settings tab and enter Logout URL and then upload the SP Cert which comes from the Keeper Admin Console.

To first download the SP Cert, view the SSO configuration on Keeper and click the Export SP Cert button.

Next, Copy and Paste the SLO Endpoint information into the SSO Settings page in the CloudGate screen.

(6) Last step is to export the metadata from "IDP Information for SMAL2.0" at SSO Settings tab to import it into the Keeper SSO Connect Cloud™.

Set the IDP Type to GENERIC and upload this file into the Keeper SSO Connect Cloud™ provisioning interface by dragging and dropping the file into the edit screen:

Assign Users

From CloudGate, you can now add users at User Settings tab on User Management page.

Please make sure if there is "Email address" value at at User Settings tab on User Management page.

Click "Save" to complete the configuration of Keeper SSO Connect Cloud with CloudGate.

Your Keeper SSO Connect setup is now complete!

CloudGate SCIM Provisioning

To enable CloudGate SCIM user and group provisioning please follow the instructions found in within the Keeper Enterprise Guides.

Move existing users/initial admin to SSO authentication

An admin can not move themselves to the SSO enabled node. It requires another admin to perform this action.

Once the user has authenticated with SSO, they only need to use their email address moving forward to initiate SSO authentication.

Traitware

How to configure Keeper SSO Connect Cloud with Traitware for Passwordless login to Keeper.

Configure Keeper for Traitware Integration

Visit the Keeper Admin Console and login as the Keeper Administrator. https://keepersecurity.com/console (US / Global) https://keepersecurity.eu/console (EU-hosted customers) https://keepersecurity.com.au/console (AU-hosted customers) https://govcloud.keepersecurity.us/console (GovCloud customers)

Note: Passwordless integration can only be applied to specific nodes (e.g. organizational units) within your Admin Console.

Click on the Admin tab and click Add Node.

From the Provisioning tab, click Add Method

Select Single Sign-On with SSO Connect™ Cloud and click Next

Enter your Configuration Name and Enterprise Domain, then click Save. Take note of the Enterprise Domain. This will be used later for Enterprise SSO login.

The newly-created SAML 2.0 with Cloud SSO Connect provisioning method will be visible. Select View from the menu.

Note the Entity ID and Assertion Consumer Service (ACS) Endpoint. These values will be used when configuring TraitWare.

Configure TraitWare

Log into the TraitWare Admin Console (TCC)

Generate Application Key

Select the Signing Keys from the left menu. Click Generate new Key Pair button. Enter the application name for the key pair. Select desired Lifetime in Years, Product Key Type and Product Key Size. Click Generate Key.

Create Traitware Application

Select Applications from the left menu and click Add Application.
Select SAML 2.0.
Click Use a Template and select Keeper

Configure SAML 2.0 Integration

From the Traitware Admin Console Applications tab, select Keeper
Select the Provider Credentials tab and click the download icon for Traitware IdP SAML Metadata (XML)
Click Save Application

From the Traitware Admin Console Users tab, select Create User
Complete the form and click Save Changes
Click on the newly created user and select the Applications tab

Note: A user with the same email address must also exist within the Keeper Admin Console. For more information on creating Keeper users, see in our enterprise documentation.

From the Traitware Admin Console Applications tab, select Keeper
Click Enable All User Access
Confirm the action and click Enable Access

Users may login either using their enterprise domain or email address.

Navigate to the Keeper Vault
Enter your email address and click Next
From your Traitware app on your smart device, scan the QR code on your desktop browser
You will now be logged in to your Keeper vault

Login Using Enterprise Domain

Navigate to the Keeper Vault
Click the Enterprise SSO Login dropdown and select Enterprise Domain
Enter the Enterprise Domain name you specified in the Keeper portion of this walkthrough and click Connect

CLI Approvals

Commander Approvals

Commander Method for Automated Approvals

Keeper Commander, our CLI and SDK platform is capable of performing Admin Device Approvals for automated approval without having to login to the Admin Console. Admin approvals can be configured on any computer that is able to run Keeper Commander (Mac, PC or Linux).

This method does not require inbound connections from the Keeper cloud, so it could be preferred for environments where ingress ports cannot be opened. This method uses a polling mechanism (outbound connections only).

Install Keeper Commander

Please see the Installation Instructions here: You can install the binary versions for Mac/PC/Linux or use pip3.

Use CLI for Device Approvals

Enter the Commander CLI using the "keeper shell" command. Or if you installed the Commander binary, just run it from your computer.

Use the "login" command to login as the Keeper Admin with the permission to approve devices. Commander supports SSO, Master Password and 2FA. For the purpose of automation, we recommend creating a dedicated Keeper Admin service account that is specifically used for device approvals. This ensures that any changes made to the user account (such as policy enforcements) don't break the Commander process.

Type "device-approve" to list all devices:

To manually approve a specific device, use this command:

To approve all devices that come from IPs that are recognized as successfully logged in for the user previously, use this command:

To approve all devices regardless of IP address, use this command:

To deny a specific device request, use the "deny" command:

To deny all approvals, remove the Device ID parameter:

To reload the latest device approvals without having to exit the shell, use the "reload" command:

Automatically Approving Devices every X seconds

Commander supports an automation mode that will run approvals every X number of seconds. To set this up, modify the config.json file that is auto-created. This file is located in the OS User's folder under the .keeper folder. For example: C:\Users\Administrator\.keeper\config.json on Windows or /home/user/.keeper/config.json on Mac/Linux.

Leave the existing data in the file and add the following lines :

JSON files need a comma after every line EXCEPT the last one.

Now when you open Commander (or run "keeper shell"), Commander will run the commands every time period specified. Example:

Automatically Approving Teams and Users

Similar to the example above, Commander can automatically approve Team and User assignments that are created from SCIM providers such as Azure, Okta and JumpCloud.

To set this up, simply add one more command team-approve to the JSON config file. For example:

Persistent Sessions

Keeper Commander supports "persistent login" sessions which can run without having to login with a Master Password or hard-code the Master Password into the configuration file.

Commands to enable persistent login on a device for 30 days (max):

You can use seconds as the value (e.g. 60 for 60 seconds) or numbers and letters (e.g. 1m for one minute, 5h for 5 hours, and 7d for 7 days).

Also note that typing "logout" will invalidate the session. Just "quit" the Commander session to exit.

Once persistent login is set up on a device, the config.json in the local folder will look something like this:

Additional information about persistent login sessions and various options is available .

There are many ways to customize, automate and process automated commands with Keeper Commander. To explore the full capabilities see the .

Docker Compose

Installation of Keeper Automator using the Docker Compose method

This guide provides step-by-step instructions to publish Keeper Automator on any Linux instance that can run Docker and Docker Compose.

Make sure you already have your SSL Certificate! If not, please follow the steps in the Create SSL Certificate page.

Docker Compose benefits over standard Docker:

Data is preserved between container updates
Future updates are simple to install and maintain

Instructions for installing Automator using the Docker Compose method are below.

(1) Install Docker and Docker Compose

Instructions for installing Docker and Docker Compose vary by platform. Please refer to the official documentation below:

On Linux, a quick guide to installing Docker and Docker Compose:

Note: On Linux you may use docker-compose instead of docker compose.

After installing, you may still need to start the Docker service, if it's not running.

Then configure the service to start automatically

To allow non-root users to run Docker (and if this meets your security requirements), run this command:

(2) Create docker-compose.yml file

Save the snippet below as the file docker-compose.yml on your server, in the location where you will be executing docker compose commands.

(3) Install the Container and Start it up

(4) Copy the SSL Certificate and password file created from page

(5) Restart the service with the new cert

(6) Install Keeper Commander

At this point, the service is running but it is not able to communicate with Keeper yet.

On your workstation, server or any computer, install the Keeper Commander CLI. This is just used for initial setup. The installation instructions including binary installers are here: After Commander is installed, you can type keeper shell to open the session, then login using the login command. In order to set up Automator, you must login as a Keeper Administrator, or an Admin with the ability to manage the SSO node.

(7) Initialize with Commander

The Node Name (in this case "Azure Cloud") comes from the Admin Console UI as seen below.

The output of the command will display the Automator settings, including metadata from the identity provider.

Note that the "URL" is not populated yet. Edit the URL with the FQDN you selected.

Run the "automator edit" command as displayed below, which sets the URL and also sets up the skills (team, team_for_user and device).

Next we exchange keys: The enterprise private key encrypted with the Automator public key is provided to Automator:

Initialize the Automator with the new configuration

Enable the service

At this point, the configuration is complete.

For automated health checks, you can use the below URL:

https://<server>/health

Example:

Monitoring Logs

The Automator logs can be monitored by using the Docker Compose command:

For environments using AD FS ...

When activating Keeper Automator with AD FS as the identity provider, users will not be able to login until you update the Keeper certificate using the instructions below:

Login to the Keeper Admin Console
Go to Admin > SSO Node > Provisioning and then view the SSO Cloud configuration.
Click on "Export SP Cert".
In the AD FS Management Console select the Keeper Cloud SSO Relying Party Trust properties.

Securing the Service

We recommend restricting network access to the service. Please see the section for a list of IP addresses to allow.

Updating

When a new version of Automator is available, updating the container is the only requirement.

Testing the User Experience

Now that Keeper Automator is deployed, you can test the end-user experience. No prompts for approval will be required after the user authenticates with the SSO identity provider.

The easiest way to test is to open an incognito mode window to the Keeper Web Vault and login with SSO Cloud. You will not be prompted for device approval.

Beyond Identity

How to configure Keeper SSO Connect Cloud with Beyond Identity for Passwordless login to Keeper.

Configure Keeper for Beyond Identity Integration

Please complete the steps in the Admin Console Configuration section first.

Visit the and login as the Keeper Administrator.

(US / Global) (EU-hosted customers) (AU-hosted customers) (GovCloud customers)

Note: Passwordless integration can only be applied to specific nodes (e.g. organizational units) within your Admin Console.

1) Click on the Admin tab and click Add Node

2) Name the node and click Add Node

3) From the Provisioning tab, click Add Method

4) Select Single Sign-On with SSO Connect™ Cloud and click Next

5) Enter your Configuration Name and Enterprise Domain, then click Save. Take note of the Enterprise Domain. This will be used later for Enterprise SSO login.

6) The newly-created SAML 2.0 with Cloud SSO Connect provisioning method will be visible. Select View from the menu.

These items will be used when configuring Beyond Identity later in the documentation.

7) Note the Entity ID, Assertion Consumer Service (ACS) Endpoint and Single Logout Service Endpoint

8) Click Export SP Cert

Configure Beyond Identity

1) for your device.

2) Log into the Beyond Identity Admin Console at .

Instructions for registering and using Beyond Identity can be found in

Create Keeper Integration in Beyond Identity

3) From your Beyond Identity Admin Console, select Integrations from the left-hand navigation.

4) Click the SAML tab.

5) Click Add SAML Connection.

6) In the Edit SAML Connection dialog, use the following table to determine values to enter:

Beyond Identity Field

Value to Use

7) In the Attribute Statements section, add the following two attributes:

Name

Name Format

Value

8) Click Save Changes.

9) Click the Download Metadata icon </> to download the XML metadata for use in the Keeper Admin Console.

10) Return to the Keeper Admin Console

11) Click Edit on the Beyond Identity provisioning method to view the configuration settings.

12) Optionally enable Just-In-Time Provisioning to allow users to create accounts in the node by typing in the Enterprise Domain name when signing up.

13) Under SAML Metadata, upload the metadata.xml file downloaded from the Beyond Identity Admin Console.

User Provisioning

Instructions on how to provision users with SSO Connect Cloud can be found .

Users may login either using their enterprise domain or email address.

1) Navigate to the Keeper Vault

2) Enter your email address and click Next

3) You will now be logged in to your Keeper vault

Login Using Enterprise Domain on desktop with Beyond Identity Authenticator installed

1) Navigate to the Keeper Vault

2) Click the Enterprise SSO Login dropdown and select Enterprise Domain

3) Enter the Enterprise Domain name you specified in the Keeper portion of this walkthrough and click Connect

4) You will now be logged in to your Keeper vault

Login Using Enterprise Domain with Beyond Identity installed for iOS or Android

1) Navigate to the Keeper Vault

2) Tap Use Enterprise SSO Login dropdown

3) Enter the Enterprise Domain you specified in the Keeper portion of this walkthrough and tap Connect

4) Accept the push notification from the Beyond Identity App

5) You will now be logged in to your Keeper vault

Login Using Email Address with Beyond Identity installed for iOS or Android

1) Open the Keeper App

2) Enter your email address and click Next

3) Accept the push notification from the Beyond Identity App

4) You will now be logged in to your Keeper vault

Windows Service

Keeper Automator sample implementation on a Windows server

The instructions on this page are created for customers who would like to simply run the Automator service on a Windows server without Docker.

Make sure you already have your SSL Certificate! If not, please follow the steps in the Create SSL Certificate page.

(1) Install the Automator Service

On the Automator instance, download, unzip and run the Keeper Automator installer:

In the setup screens, check the "Java" box to ensure that the Java runtime is embedded in the installation. Currently it ships with the Java 17 runtime, and this is updated as new versions are released.

This will install Keeper Automator into:

C:\Program Files\Keeper Security\Keeper Automator\

The configuration and settings will be set up in:

C:\ProgramData\Keeper Automator\

(2) Create the "config" folder

In the C:\ProgramData\Keeper Automator\ folder please create a folder called "config".

(3) Copy the certificate file and password file

Place ssl-certificate.pfx file (from the page) to the Automator Configuration settings folder in C:\ProgramData\Keeper Automator\Config

If your ssl-certificate.pfx file is protected by a passphrase, you also need to create a file called ssl-certificate-password.txt in the folder C:\ProgramData\Keeper Automator\Config

(4) Restart the Service

From the Services screen, select Keeper Automator and Restart the the service.

Confirm the service is running through a web browser (note that port 443 must be opened from whatever device you are testing) In this case, the URL is: https://automator.company.com/api/rest/status

For automated health checks, you can also use the below URL:

https://automator.company.com/health

Windows Firewall

If you are deploying on Windows running Defender Firewall, most likely you will need to open port 443 (or whatever port you specified) on Windows Defender Firewall. Follow these steps:

Open the Start menu > type Windows Defender Firewall, and select it from the list of results. Select Advanced settings on the side navigation menu... Select Inbound Rules. To open a port, select New Rule and complete the instructions.

Here's a couple of screenshots:

Final Configuration with Commander

Now that the service is running, you can integrate the Automator into your Keeper environment using Keeper Commander.

(5) Install Keeper Commander

On your workstation or server, install Keeper Commander CLI. The installation instructions including binary installers are here: (6) Login to Keeper Commander and activate the Automator using a series of commands, starting with automator create and name the automator whatever you want.

The Node Name (in this case "Azure Cloud") comes from the Admin Console UI as seen below.

The output of the command will display the Automator settings, including metadata from the identity provider.

Note that the "URL" is not populated yet. So let's do that next.

Run the "automator edit" command as displayed below, which sets the URL and also sets up the skills (team, team_for_user and device).

Next we exchange keys: The enterprise private key encrypted with the Automator public key is provided to Automator:

If an error is generated on this step, please stop and start the Windows service, and ensure that the port is available.

Next, initialize the Automator with the new configuration with the command below:

Lastly, enable the Automator service with the following command:

At this point, the configuration is complete.

For environments using AD FS ...

When activating Keeper Automator with AD FS as the identity provider, users will not be able to login until you update the Keeper certificate using the instructions below:

Login to the Keeper Admin Console
Go to Admin > SSO Node > Provisioning and then view the SSO Cloud configuration.
Click on "Export SP Cert".
In the AD FS Management Console select the Keeper Cloud SSO Relying Party Trust properties.

Testing the User Experience

Now that Keeper Automator is deployed, you can test the end-user experience. No prompts for approval will be required after the user authenticates with the SSO identity provider.

The easiest way to test is to open an incognito mode window to the Keeper Web Vault and login with SSO Cloud. You will not be prompted for device approval.

Service Updates

When you reconfigure the Keeper Automator service, you'll need to use Keeper Commander to re-initialize the service endpoint.

Troubleshooting

Service not starting

Please check the Keeper Automator logs. This usually describes the issue. On Windows, they can be found in C:\ProgramData\Keeper Automator\logs\

Users always getting prompted for approval

When you reinstall the Keeper Automator service, you'll need to use Keeper Commander to re-initialize the service endpoint. (Keeper Commander documentation is ).

The commands required on Keeper Commander to re-initialize your Automator instance:

Other SAML 2.0 Providers

How to configure Keeper SSO Connect Cloud with your SSO Identity Provider for seamless and secure SAML 2.0 authentication.

Please complete the steps in the Admin Console Configuration section first.

Keeper is compatible with any SAML 2.0 SSO Identity Provider (IdP). If your identity provider is not in our list, you can follow the steps in this guide to complete the configuration. Keeper is a Service Provider (SP) in this configuration.

Step 1: Configure your Identity Provider

You'll need to provide some information about Keeper SSO Connect Cloud to your Identity Provider application such as:

Entity ID
IDP Initiated Login
Assertion Consumer Service (ACS) Endpoint
Single Logout Service (SLO) Endpoint

To obtain this information, locate your SSO Connect Cloud Provisioning method within the Keeper Admin Console, and select View. From there you have access to download the Keeper metadata file, service provider (SP) certificate file as well as the direct URLs and configuration information (if your identity provider application does not support uploading of the metadata file).

Refer to your identity provider application configuration guide for instructions on how to upload service provider metadata and or manually inputting the required SAML response configuration fields.

Step 2: Obtain your IdP Metadata

To import your IdP Metadata into Keeper, you will need to have a properly formatted metadata file. If your SSO Identity Provider Application has the ability to export its metadata file, this would be the most expedient and preferred method to import your metadata into your Keeper SSO Connect Cloud Provisioning method.

If you do not have the ability to export / download your metadata file from your identity provider, please create a properly formatted metadata file. Refer to your SSO application's configuration guide for instructions.

Below is an example / template of what a simple identity provider metadata.xml file, against Keeper SSO Connect Cloud should look like. If you need to use this example / template to get you started, please Copy, Paste, Modify and add any other fields, in accordance to your IdP information, in your preferred .xml or .txt editor.

Please DO NOT remove any fields as this example contains the minimum required fields to connect your SSO application to Keeper.

Step 3: Map User Attributes

Keeper requires that you map specific User Attributes to be sent during authentication. Default Keeper SSO Connect Cloud User Attributes are Email, First and Last, as outlined in the table below. Ensure your identity provider's User Attributes are lined up with Keeper's attributes. Refer to your Identity Provider's configuration guide for instructions.

Step 4: Upload IdP Metadata to Keeper

Once you have completed creating your identity provider metadata file, or if you have downloaded the identity provider metadata file, head back to the Keeper Admin console, locate your SSO Connect Cloud Provisioning method and select Edit.

Scroll down to the Identity Provider section, set IDP Type to GENERIC, select Browse Files and select the Metadata file you created.

Still within the Keeper Admin Console, exit the Edit View and select View on your SSO Connect Cloud Provisioning method. Within the Identity Provider section you will find the metadata values for the Entity ID, Single Sign On Service and Single Logout Service Endpoint that are now populated.

Graphic Assets

If your identity provider requires an icon or logo file for the application, please see the .

Success! Your Keeper Security SSO Cloud setup is now complete! You may now try logging into Keeper with SSO.

If you find that your application is not functional, please review your identity provider application settings and review your metadata file and user attributes for any errors.

Once complete, repeat Step 4.

If you need assistance, please email [email protected].

Move existing users/initial admin to SSO authentication

An admin can not move themselves to the SSO enabled node. It requires another admin to perform this action.

Once the user has authenticated with SSO, they only need to use their email address moving forward to initiate SSO authentication.

Google Cloud with GCP Cloud Run

Running the Keeper Automator service on the Google Cloud platform with Cloud Run

Overview

This guide provides step-by-step instructions to run the Keeper Automator service on Google Cloud, specifically using the GCP Cloud Run service. The Automator is also protected by the Google Armor service in order to restrict access to Keeper's infrastructure IPs.

(1) Create a Project

From the Google Cloud console () create a new project.

Then click "Select Project" on this new project.

(2) Start the Cloud Shell

For this documentation, we'll use the Google Cloud Shell from the web interface. Click to activate the Cloud Shell or install this on your local machine.

Note the Project ID, which in this case is keeper-automator-439714. This Project ID will be used in subsequent commands.

(3) Link a Billing Account

If you haven't done so, you must link a valid Billing account to the project. This is performed in the Google Cloud user interface from the Billing menu.

(3) Create an Automator Config key

From the Cloud Shell, generate a 256-bit AES key in URL-encoded format:

Example key: 6C45ibUhoYqkTD4XNFqoZoZmslvklwyjQO4ZqLdUECs=

Save the resulting Key in Keeper. This will be used as an environment variable when deploying the container. This key ensures that ephemeral containers will be configured at startup.

(4) Enable the Artifact Registry

(5) Select a Region

You need to select a region for the service to run. The available region codes can be found by using the following command:

For this example, we will use us-east1

(6) Create Artifact Repository for the Automator service

Run the below 2 commands, replacing "us-east1" with your preferred value from Step 5

(7) Upload the Automator container to the Artifact Registry

Create a file called cloudbuild.yaml that contains the following content, ensuring to replace the string "us-east1" with your preferred location from Step 5. Leave all other content the same.

Replace us-east1 with your preferred location from

Upload this file through the Cloud Shell user interface, or create the text file in the cloud shell.

From the Cloud Shell, execute the following:

Then execute the build:

This will sync the latest Automator container to your Google Artifact Registry.

(8) Deploy the Automator service

The following command will deploy the Keeper Automator service to Google Cloud Run from your Artifact Registry. This service is limited to internal access and load balancers only.

Note the following:

[PROJECT_ID] needs to be replaced by your Project ID as found in Step 2
XXX is replaced with the configuration key that you created in Step 3 above.
AUTOMATOR_PORT tells the container to listen on port 8080

(9) Create Managed Certificate

The Keeper system is going to communicate with your Automator service through a publicly routable DNS name. In this example, I'm using gcpautomator.lurey.com. In order to set this up, you need to first create a managed SSL certificate. The command for this is below.

Replace gcpautomator.lurey.com with your desired name

(10) Create a Serverless Network Endpoint Group

The next command links the Cloud Run service to a Google Cloud Load Balancer.

Replace us-east1 with the region of your Cloud Run service from .

(11) Create a backend service that will use the NEG

This creates a backend service that links to the Cloud Run service:

(12) Attach the NEG to the backend service

This attaches the NEG to the backend service.

Replace us-east1 with the desired location specified in

(13) Create a URL map that directs incoming traffic to the backend service

(14) Create the HTTPS target proxy and map the Automator certificate

(15) Reserve a static IP address and assign DNS entry

Get the IP address and note for later:

The IP address must be mapped to a valid DNS.

In your DNS provider, set up an A-record pointing to the IP.

Example A-Record Configuration

Type

Name

Value

TTL

This step is important. Ensure that the desired domain name is pointing to the IP address provided. This step must be performed in your DNS provider directly.

(16) Create a Global Forwarding Rule

Create a global forwarding rule to direct incoming requests to the target proxy:

(17) Lock down access to specific IPs

The Keeper Automator service should be restricted to only the necessary IPs as discussed on the page.

Let's create a Cloud Armor Security Policy to restrict access to certain IP addresses

In this step, we will attach IPs Keeper's US Data Center as found . Additional rules can be created as you see fit.

We recommend adding your external IP to this list, so that you can test the Automator service

We will also add a default "deny" rule to restrict other traffic:

Finally, attach the Cloud Armor security policy to the backend service

At this point, the Automator service should be running and the service should be exposed only to the Keeper infrastructure.

The next step is to finish the configuration with the Keeper Commander utility.

Keeper Commander is required to perform the final step of Automator configuration. This can be run from anywhere, it does not need to be installed on the server.

On your workstation or server, install Keeper Commander CLI. The installation instructions including binary installers are here: After Commander is installed, launch Keeper Commander, or from an existing terminal you can type keeper shell to open the session, then login using the login command. In order to set up Automator, you must login as a Keeper Administrator, or an Admin with the ability to manage the SSO node.

(19) Create the Automator

Create the Automator using a series of commands, starting with automator create

The Node Name (in this case "Azure Cloud") comes from the Admin Console UI as seen below.

The output of the command will display the Automator settings, including metadata from the identity provider.

Note that the "URL" is not populated yet. This will be populated with the automator URL.

Run the "automator edit" command as displayed below, which sets the URL and also sets up the skills (team, team_for_user and device).

NOTE: Replace gcpautomator.lurey.com with the domain name you created in

Next we exchange keys: The enterprise private key encrypted with the Automator public key is provided to Automator:

Initialize the Automator with the new configuration

Enable the service

Testing the User Experience

Now that Keeper Automator is deployed, you can test the end-user experience. No prompts for approval will be required after the user authenticates with the SSO identity provider.

The easiest way to test is to open an incognito mode window to the Keeper Web Vault and login with SSO Cloud. You will not be prompted for device approval.

Updating the Container

To update the container in Google when there is a new version available from Keeper, run the following commands:

Repeat
Repeat

Need help?

If you need assistance, please email [email protected] or open a .

Kubernetes Service

Installation of Keeper Automator as a Kubernetes service

This guide provides step-by-step instructions to publish Keeper Automator as a Kubernetes service.

Make sure you already have your SSL Certificate! If not, please follow the steps in the Create SSL Certificate page.

(1) Set up Kubernetes

Installation and deployment of Kubernetes is not the intent of this guide, however a very basic single-node environment using two EC2 instances (Master and Worker) without any platform dependencies is documented here for demonstration purposes. assuming you already have your K8 environment running.

Set up Docker

Kubernetes requires a container runtime, and we will use Docker.

Install kubeadm, kubelet, and kubectl

These packages need to be installed on both master and worker nodes. The example here is using AWS Amazon Linux 2 instance types.

Initialize the Master Node

On the machine you want to use as the master node, run:

The --pod-network-cidr argument is required for certain network providers. Substitute the IP range you want your pods to have.

After kubeadm init completes, it will give you a command that you can use to join worker nodes to the master. Make a note of the response and initialization code for the next step.

Set up the local kubeconfig:

Install a Pod Network

You need to install a Pod network before the cluster will be functional. For simplicity, you can use flannel:

Join Your Worker Nodes

On each machine you want to add as a worker node, the command below with the initialization code.

Note that port 6443 must be open between the worker and master node in your security group.

After the worker has been joined, the Kubernetes cluster should be up and running. You can check the status of your nodes by running kubectl get nodes on the master.

(2) Create a Kubernetes Secret

The SSL certificate for the Keeper Automator is provided to the Kubernetes service as a secret. To store the SSL certificate and SSL certificate password (created from the ), run the below command:

(3) Create a Manifest

Below is a manifest file that can be saved as automator-deployment.yaml. This file contains configurations for both a Deployment resource and a Service resource.

The deployment resource runs the Keeper Automator docker container
The SSL certificate and certificate password files are referenced as a mounted secret
The secrets are copied over to the pod in an initialization container
The Automator service is listening on port 30000 and then routes to port 443 on the container.

(4) Deploy the Service

The service should start up within 30 seconds.

(5) Check Service Status

Confirm the service is running through a web browser (note that port 30000 must be opened from whatever device you are testing). In this case, the URL is: https://automator2.lurey.com:30000/api/rest/status

For automated health checks, you can also use the below URL:

https://<server>/health

Example:

Now that the service with a single pod is running, you need to integrate the Automator into your environment using Keeper Commander.

(6) Configure the Pod with Commander

Keeper Commander is required to configure the pod to perform automator functions. This can be run from anywhere.

On your workstation, install Keeper Commander CLI. The installation instructions including binary installers are here: After Commander is installed, you can type keeper shell to open the session, then login using the login command. In order to set up Automator, you must login as a Keeper Administrator, or an Admin with the ability to manage the SSO node.

The Node Name (in this case "Azure Cloud") comes from the Admin Console UI as seen below.

The output of the command will display the Automator settings, including metadata from the identity provider.

Note that the "URL" is not populated yet. So let's do that next.

Run the "automator edit" command as displayed below, which sets the URL and also sets up the skills (team, team_for_user and device).

Next we exchange keys: The enterprise private key encrypted with the Automator public key is provided to Automator:

Next, send other IdP metadata to the Automator:

Enable the Automator service

At this point, the configuration is complete.

(7) Securing the Service

We recommend limiting network access to the service from Keeper's servers and your own workstation. Please see the section for a list of Keeper IP addresses to allow.

(8) Test the Automator Service

To ensure that the Automator service is working properly with a single pod, follow the below steps:

Open a web browser in an incognito window
Login to the Keeper web vault using an SSO user account
Ensure that no device approvals are required after successful SSO login

(9) Update the Pod configuration

At this point, we are running a single pod configuration. Now that the first pod is set up with the Automator service and configured with the Keeper cloud, we can increase the number of pods.

Update the "replicas" statement in the YAML file with the number of pods you would like to run. For example:

Then apply the change:

With more than one pod running, the containers will be load balanced in a round-robin type of setup. The Automator pods will automatically and securely load their configuration settings from the Keeper cloud upon the first request for approval.

Troubleshooting the Automator Service

The log files running the Automator service can be monitored for errors. To get a list of pods:

Connect via terminal to the Automator container using the below command:

The log files are located in the logs/ folder. Instead of connecting to the terminal, you can also just tail the logfile of the container from this command:

Azure Container App

Simple Deployment with Azure Container App

Overview

This guide provides step-by-step instructions to publish Keeper Automator to the Azure Container App service. This provides a simple and straightforward way to host the Automator service in the cloud.

For environments such as Azure Government, GCC High and DoD, use the , since the Azure Container App service may not be available in those regions.

(1) Create an Automator Config key

Open a command line interface and generate a 256-bit AES key in URL-encoded format using one of the methods below, depending on your operating system:

Generate a Key

Save the resulting value produced by this command for Step (3).

(2) Create a Container Registry

If you do not already have a container registry, you must create one and configure as you see fit. Example below.

(3) Create a Container App

From Azure, create a new Container App.

Select or create a new Resource Group
Set the Container App Name to "keeperautomator" or whatever you prefer
Select "Container Image" as the Deployment Source
Select the region where you would like the service hosted

(4) Setup Container Details

In the "Container" step, make the following selections:

Uncheck the "Use quickstart image"
Select "Docker Hub or other registries"
Select "Public"
Select Registry login server as

(5) Ingress Setup

On the Ingress setup screen, select the following:

Enable Ingress
Ingress traffic Accepting traffic from anywhere (we'll modify this in a later step)
Ingress type HTTP

(6) Create Container App

Click "Review + Create" and then click "Create"

After a few minutes, the container app will be created and automatically start up.

Clicking on "Go to Resource" will take you to the container environment.

(7) Customize the Ingress Setup

To restrict communications to the Keeper Automator service, click on the "Ingress" link on the left side of the screen under the "Network" section

Click on "Ingress"
Select "Allow traffic from IPs configured below, deny all other traffic"
Click "Add" to add and any of your IPs required for testing the service. Ingress Requirements information:

If you want to be able to run a health check, then consider adding your own IP address. Find your IP address at

(8) Set Scaling

Select Application > Scale and set min and max replicas to 1
Click "Save as a new revision"

(9) Create Volume

Select Application > Volumes and click "+ Add"
Add a Ephemeral Storage and name it as you wish and click "Add"

Then click "Save as a new revision"

(10) Set up Health Probes and Volume Mount

Navigate to the "Application > Revisions and Replicas" section"

Click on "Create new revision"

Click on Application > Revisions and replicas an observe a new revision being activated

Next, click on the "Container" tab
Click on the container image name link, in this case "keeperautomator" at the bottom

Navigate to Health Probes and enter the following under each section:

Under "Liveness probes":

Enable liveness probes
Transport: HTTP
Path: /health

Under "Startup probes":

Enable startup probes
Transport: HTTP
Path: /health

Under "Volume Mounts" tab:

Select "+ Add"
Select the volume you created in a previous step and Add Mount Path as /usr/mybin/config

Finish the configuration

Click on Save
Then click on Create to build the new configuration
After a few minutes, the new containers should start up

(11) Retrieve the Application URL

Wait until the revision is done activating.

From the Overview section of the Container App, on the right side is the "Application URL" that was assigned. Copy this and use this Application URL in the next step.

For example, https://craigautomator1.xyx-1234.azurecontainerapps.io

Keeper Commander is required to perform the final step of Automator configuration. This can be run from anywhere, it does not need to be installed on the server.

(13) Create the Automator

Create the Automator using a series of commands, starting with automator create with your node name.

The Node Name (in this case "Azure Cloud") comes from the Admin Console UI as seen below.

The output of the command will display the Automator settings, including metadata from the identity provider.

Note that the "URL" is not populated yet. This is the Application URL from Step 8.

Run the "automator edit" command as displayed below, which sets the URL and also sets up the skills (team, team_for_user and device).

Next we exchange keys: The enterprise private key encrypted with the Automator public key is provided to Automator:

Initialize the Automator with the new configuration

Enable the service

At this point, the configuration is complete.

For external health checks, you can use the below URL:

https://<server>/health

Example curl command:

Testing the User Experience

Now that Keeper Automator is deployed, you can test the end-user experience. No prompts for approval will be required after the user authenticates with the SSO identity provider.

The easiest way to test is to open an incognito mode window to the Keeper Web Vault and login with SSO Cloud. You will not be prompted for device approval.

Advanced

Azure Container Apps have many advanced capabilities that are beyond the scope of this documentation. A few of the capabilities are provided below.

Scaling with Multiple Containers

If you would like to have multiple containers running the Keeper Automator service:

Click on "Scale and replicas"
Click "Edit and deploy"
Click on the "Scale" tab
Select the min and max number of containers. The minimum should be at least 1.

Logging

The Keeper Automator logs can be viewed and monitored using the "Console" or "Log stream" section.

For example, to tail the log file of a running Automator service:

Click on Console
Select "/bin/sh"
Click Connect
At the prompt, type: tail -f logs/keeper-automator.log

Advanced Settings

Environment variables can be passed into the Container to turn on/off features of the runtime environment. The variables with their description can be found at the page.

Google Workspace User and Group Provisioning with Cloud Function

Step by Step guide to automatically provisioning Users and Groups from Google Workspace using a Cloud Function

Overview

This document describes how to automatically provision users from Google Workspace to Keeper using a Google Cloud Function, which includes the provisioning of Users, Groups and user assignments. User and Team Provisioning provides several features for lifecycle management:

You can specify which Google Groups and/or users are provisioned to Keeper
Matching of Groups can be performed by Group name or Group email
Google Groups assigned to Keeper are created as Keeper Teams
Keeper Teams can be assigned to Shared Folders in the vault

The setup steps in this section allow you to provision users and groups from your Google Workspace account. Setting up this method requires access to several resources:

Keeper Secrets Manager is used in this implementation to perform the most secure method of integration between Google and Keeper, ensuring least privilege. If you don't use Keeper Secrets Manager, please contact the Keeper customer success team.

STEP 1: Create a Google Cloud Project

Login to and create a project or chose an existing project. The project name can be "Keeper SCIM Push" or whatever you prefer.

STEP 2: Enable the Admin SDK API

In the APIs & Services click +ENABLE APIS AND SERVICES
In the Search for APIs & Services enter Admin SDK API
Click ENABLE

STEP 3: Create a Service Account

The service account created here will be used to access the Google Workspace user and group information.

In the IAM and Admin menu select Service accounts
Click +CREATE SERVICE ACCOUNT with suggested service account name: keeper-scim

For newly created service account click Actions/dots and select Manage Keys

Click ADD KEYS -> Create New Key. Choose JSON key type then CREATE

A JSON file with service account credentials will be downloaded to your computer

Rename this file to credentials.json and add this file as attachment to your Keeper configuration record that was created in the Setup Steps above.

STEP 4: Copy the Client ID

Navigate to your Service Account and select DETAILS tab > Advanced Settings

In the Domain-wide delegation section copy the Client ID. You will need to grant this Client ID access to the Google Workspace Directory in the next step.

STEP 5: Authorize Service Account on Google Workspace

In the Google Workspace Panel ():

Navigate to Security -> API controls
Under the Domain wide delegation click MANAGE DOMAIN WIDE DELEGATION
Click Add new in API Clients

Paste the following text into OAuth scopes (comma-delimited)

Click AUTHORIZE - These scopes grant Service Account read-only access to Google Workspace Directory Users, Groups and Membership.

STEP 6: Retrieve the Primary Email

In Google Workspace (), navigate to Account -> Account settings
Copy the Primary admin email into the clipboard (upper right area) for use in the next step.

STEP 7: Create a Shared Folder in your Keeper Vault

In your Keeper Vault, create a new Shared Folder. This folder can be named anything, for example "Google SCIM Push". The user and record permissions for this folder can be set any way you prefer.

STEP 8: Create a Secrets Manager Application

Assuming that you have enabled and activated for this vault, click on Secrets Manager from the left side and then select Create Application.

Call the Application name "Google SCIM Push" (or whatever you prefer) and click Generate Access Token. This token will be discarded and not used in this scenario.

Next, select the "Google SCIM Push" application from the list, and click on Edit then Add Device.

Select the base64 configuration and download it to your computer.

Save the file to your computer as config.base64.

STEP 9: Create a SCIM Provisioning Method

From the Keeper Admin Console, go to the Provisioning tab for the Google Workspace node and click "Add Method".

Select SCIM and click Next.

Click on "Create Provisioning Token"

The URL and Token displayed on the screen will be used in the next step. Save the URL and Token in a file somewhere temporarily and then click Save.

Make sure to save these two parameters (URL and Token) and then click Save. These parameters are used in the next step.

STEP 10: Create a Keeper Record in the Shared Folder

Inside the Shared Folder created in step 7, create a Keeper record that contains the following fields:

Field

Value

All Groups and users within the specified Groups will be provisioned to Keeper.

You can specify either the Group Email address or the Group Name in the list of groups. Keeper will match either value and provision all associated users and groups.

The Group Name and Group Email is CASE SENSITIVE

At this point, the configuration on Keeper is complete. The remaining steps are performed back on the Google Cloud console by setting up a Cloud Function.

STEP 11: Create the Google Cloud Function

From the Google Cloud console, open Cloud Functions and then click CREATE FUNCTION.

Under Basics:

Select environment of "2nd gen"
Select Function name of keeper-scim-push
Select your preferred region and note this for later
Trigger is HTTPS

Under Advanced -> Runtime:

Memory allocated: 256MiB
CPU: 0.333
Timeout: 120 seconds
Concurrency: 1

If the Default compute service account does not exist yet, select a different account temporarily then go back and edit the service account after saving.

Below is an example full configuration:

In the Runtime environment variables:

Create two variables:

Set Name 1 to KSM_CONFIG_BASE64 and Value 1 to the contents of the KSM configuration file generated in Step 8
Set Name 2 to KSM_RECORD_UID and Value 2 to the record UID created in the vault in Step 10.

You can find the Record UID by clicking on the (info) icon from the Keeper vault record. Click on the Record UID to copy the value.

Click on CONNECTIONS and select "Allow internal traffic only"

Scroll down and click NEXT to upload the Cloud Function source.

STEP 12: Upload the Cloud Function Source

Visit the Keeper Google SCIM Push release page:
Download the source.zip file and save it to your computer

Select Runtime of Go 1.21
Select Source code of Zip Upload
Type Entry point of GcpScimSyncHttp

Click DEPLOY to create the Cloud Function. After a few minutes, the function will be created and published.

The function is private and requires authentication, so the next step is creating a Cloud Scheduler.

STEP 13: Copy the Cloud Function URL

From the Cloud Function screen, copy the URL as seen below:

STEP 14: Create the Cloud Scheduler

From the Google Cloud console, search for Cloud Scheduler and open it.

Click SCHEDULE A JOB

Define the schedule:

Set any description, such as "Keeper SCIM Push for Google Workspace"
Set the frequency, for example 0 * * * * for running once per hour
Set the Timezone according to your location
Set the Target type to HTTP

STEP 15: Test the Scheduler

On the Scheduler Jobs screen, the job will now be listed. To force execution, click on the overflow menu on the right side and select Force run.

This will execute the Cloud Function immediately.

If successful, the status of last execution will show success:

To ensure that Keeper received the sync information, login to the Keeper Admin Console. You will see a list of any pending / invited users, teams and team assignments.

Step 16: Delete Local Files

Once the process is working successfully, delete all local files and secrets created during this process.

IMPORTANT: Delete all local or temporary files on your computer, such as:

config.base64 file
credentials.json file

Destructive Operations

By default, "unmanaged" teams and team assignments in the Keeper Admin Console will not be deleted during the sync process. However, if your preferred method of syncing is to delete any unmanaged teams or team assignments, you can simply create a custom field in the Keeper record with a particular value.

"Destructive" Field Value

Description

Debug Logging

The Keeper record can be modified to create verbose logs in the Google Cloud Function logs.

Verbose Field Value

Description

Important Syncing Notes:

Keeper performs exact string matches on the Group Name or Group Email address when performing the Cloud Function provisioning. The group name and email is case sensitive.
Users in an invited state are not added to assigned teams until the user creates their vault and the Keeper administrator logs in to the Admin Console. Team membership can also be performed when another member of the team logs in to the vault. Clicking "Sync" from the Admin Console will also perform the additions.
Some operations such as the creation of Teams can only occur upon logging into the Keeper Admin Console, or when running the service. This is because encryption keys need to be generated.

Updating the Cloud Function Source

When new versions of the Cloud Function are created, updating the code is very simple:

Download a new source.zip file from the of the ksm-google-scim Github repo
Navigate to the Cloud Functions area of Google Cloud
Click on the cloud function details and click EDIT

AWS Elastic Container Service

Running Keeper Automator with the AWS ECS (Fargate) service

Overview

This example demonstrates how to launch the Keeper Automator service in Amazon ECS in the most simple way, with as few dependencies as needed.

Requirements:

A managed SSL certificate via the AWS

(1) Create an Automator Config key

Generate a 256-bit AES key in URL-encoded format using one of the methods below, depending on your operating system:

Mac/Linux

Windows

Save this value for the environmental variables set in the task definition.

(2) Create a VPC

If your VPC does not exist, a basic VPC with multiple subnets, a route table and internet gateway must be set up. In this example, there are 3 subnets in the VPC with an internet gateway as seen in the resource map below:

(3) Create CloudWatch Log Group

If you would like to capture logs (recommended), Go to CloudWatch > Create log group

Name the log group "automator-logs".

(4) Create an Execution IAM Role

Go to IAM > Create role

Select AWS service

Then search for Elastic Container Service and select it.

Select "Elastic Container Service Task" and click Next

Add the "AmazonECSTaskExecution" policy to the role and click Next

Assign the name "ECSTaskWritetoLogs" and then create the role.

Make note of the ARN for this Role, as it will be used in the next steps.

In this example, it is arn:aws:iam::373699066757:role/ECSTaskWritetoLogs

(5) Create a Security Group for ECS

Go to EC2 > Security Groups and click on "Create security group"

Depending on what region your Keeper tenant is hosted, you need to create inbound rules that allow https port 443 from the Keeper cloud. The list of IPs for each tenant location is located below. In the example below, this is the US data center.

We also recommend adding your workstation's external IP address for testing and troubleshooting.

Assign a name like "MyAutomatorService" and then click "Create".

Keeper Tenant Region

IP1

IP2

Remember to add your own IP which you can find from this URL:

(6) Add the Security Group to the list of inbound rules

After saving the security group, edit the inbound rules again. This time, make the following additions:

Add HTTP port 8089 with the Source set to the security group. This allows traffic from the ALB to the container inside the network and for processing health checks.

(7) Create Elastic Container Service Cluster

Navigate to the Amazon Elastic Container Service.

Select "Create cluster" and assign the cluster name and VPC. In this example we are using the default "AWS Fargate (serverless)" infrastructure option.

The Default namespace can be called "automator"
The "Infrastructure" is set to AWS Fargate (serverless)
Click Create

(8) Create ECS Task Definition

In your favorite text editor, copy the below JSON task definition file and save it.

Important: Make the following changes to the JSON file:

Change the XXX (REPLACE THIS) XXX on line 24 to the secret key created in Step 1 above.
Replace lines 37-39 with the name and location of the log group from Step 3
Change the XXX on line 44 for the role ID as specific to your AWS role (from Step 4, e.g. 373699066757)

Next, go to Elastic Container Service > Task definitions > Create Task from JSON

Remove the existing JSON and copy-paste the modified JSON file into the box, then click Create.

This task definition can be modified according to your instance CPU/Memory requirements.

(9) Upload SSL Cert to AWS Certificate Manager

In order for an application load balancer in AWS to serve requests for Automator, the SSL certificate must be managed by the AWS Certificate Manager. You can either import or create a certificate that is managed by AWS.

From AWS console, open the "Certificate Manager"
Click on Request
Request a public certificate and click Next
Enter the domain name for the automator service, e.g. automator.lurey.com

If you use Route53 to manage the domain, you can click on the certificate and then select "Create Records in Route53" to instantly validate the domain and create the certificate. If you use a different DNS provider, you need to create the CNAME record as indicated on the screen.

Once create the CNAME record, the domain will validate within a few minutes.

This certificate will be referenced in Step 11 when creating the application load balancer.

(10) Create a Target Group

Go to EC2 > Target Groups and click Create target group

Select "IP Addresses" as the target type
Enter the Target group name of "automatortargetgroup" or whatever you prefer
Select HTTP Protocol with Port 8089
Select the VPC which contains the ECS cluster

(11) Create Application Load Balancer (ALB)

Go to EC2 > Load balancers > Create load balancer

Select Application Load Balancer > Create

Assign name such as "automatornalb" or whatever you prefer
Scheme is "Internet-facing"
IP address type: IPv4
In the Network Mapping section, select the VPC and the subnets which will host the ECS service.

(12) Create ECS Service

Go to Elastic Container Service > Task definitions > Select the task created in Step 8.

From this Task definition, click on Deploy > Create Service

Select Existing cluster of "automator"
Assign Service name of "automatorservice" or whatever name you prefer
For the number of Desired tasks, set this to 1 for now. After configuration is complete, you can increase to the number of tasks you would like to have running.

After a few minutes, the service should start up.

(13) Update DNS

Assuming that the DNS name is hosted and managed by Route53:

Go to Route53 > Create or Edit record

Create an A-record
Set as "Alias"
Route traffic to "Alias to Application and Classic Load Balancer"
Select AWS Region

The next step is to configure Automator using Keeper Commander while only having one task running.

(14) Install Keeper Commander

At this point, the service is running but it is not able to communicate with Keeper yet.

(15) Initialize with Commander

The Node Name (in this case "Azure Cloud") comes from the Admin Console UI as seen below.

The output of the command will display the Automator settings, including metadata from the identity provider.

Run the "automator edit" command as displayed below, which sets the URL and also sets up the skills (team, team_for_user and device).

Next we exchange keys: The enterprise private key encrypted with the Automator public key is provided to Automator:

Initialize the Automator with the new configuration

Enable the service

At this point, the configuration is complete.

For automated health checks, you can use the below URL:

https://<server>/health

Example curl command:

In this example setup, the load balancer will be forwarding /health checks to the target instances over HTTP port 8089.

(16) Testing the User Experience

Now that Keeper Automator is deployed with a single task running, you can test the end-user experience. No prompts for approval will be required after the user authenticates with the SSO identity provider.

The easiest way to test is to open an incognito mode window to the Keeper Web Vault and login with SSO Cloud. You will not be prompted for device approval.

Assuming that the approval worked, you can now increase the number of tasks running.

(17) Update Task Definition (Optional)

The Keeper Automator service can run quite well on a single container without any issue due to the low number of requests that it processes. However if you would like to have multiple containers running, please follow the below steps:

Click on the "automatorservice" from the ECS services screen
Click on "Update service"
Select the checkbox on "Force new deployment"

For every container, the automator setup, automator init and automator enable must be executed.

For example, if there are 3 containers running:

Logging and Monitoring

The Automator logs can be searched and monitored in the "Logs" tab of the ECS service, or in CloudWatch.

AWS Elastic Container Service with KSM (Advanced)

Running Keeper Automator with the AWS ECS (Fargate) service and Keeper Secrets Manager for secret storage

Overview

This example demonstrates how to launch the Keeper Automator service in Amazon ECS with Fargate, while also demonstrating the use of Keeper Secrets Manager for retrieving the secret configuration for the published Docker container.

Keeper Setup

Since this deployment requires the use of Keeper Secrets Manager, this section reviews the steps needed to set up your Keeper vault and the SSL certificate for publishing the Automator service.

(1) SSL Certificate

Create an SSL Certificate as described

When this step is completed, you will have two files: ssl-certificate.pfx and ssl-certificate-password.txt

(2) Create Shared Folder

Create a Shared Folder in your vault. This folder will not be shared to anyone except the secrets manager application.

(3) Add File Attachments

Create a record in the Shared Folder, and make note of the Record UID. Upload the SSL certificate and SSL certificate password files to a Keeper record in the shared folder.

(4) Add Automator Property File

Upload a new file called keeper.properties which contains the following content:

The notable line here is the disable_sni_check=true which is necessary when running the Automator service under a managed load balancer.

Your shared folder and record should look something like this:

(5) Create KSM Application

Create a Keeper Secrets Manager ("KSM") application in your vault. If you are not familiar with secrets manager, . The name of this application is "Automator" but the name does not matter.

(6) Attach the KSM application to the shared folder

Edit the Shared Folder and add the Automator application to this folder.

(7) Create a KSM Device Configuration

Open the secrets manager application, click on "Devices" tab and click "Add Device". Select a base64 configuration. Download and save this configuration for use in the ECS task definition.

AWS Setup

(1) Create a VPC

(2) Create CloudWatch Log Group

Go to CloudWatch > Create log group

Name the log group "automator-logs".

(3) Create an Execution IAM Role

Go to IAM > Create role

Select AWS service

Then search for Elastic Container Service and select it.

Select "Elastic Container Service Task" and click Next

Add the "AmazonECSTaskExecution" policy to the role and click Next

Assign the name "ECSTaskWritetoLogs" and then create the role.

Make note of the ARN for this Role, as it will be used in the next steps.

In this example, it is arn:aws:iam::373699066757:role/ECSTaskWritetoLogs

(4) Create a Security Group for ECS

Go to EC2 > Security Groups and click on "Create security group"

Depending on what region your Keeper tenant is hosted, you need to create inbound rules that allow https port 443. The list of IPs for each tenant location is . In the example below, this is the US data center.

We also recommend adding your workstation's external IP address for testing and troubleshooting.

Assign a name like "MyAutomatorService" and then click "Create".

After saving the security group, edit the inbound rules again. This time, add HTTPS port 443 and select the security group in the drop-down. This will allow the load balancer to monitor health status and distribute traffic.

(5) Create Security Group for EFS

We'll create another security group that controls NFS access to EFS from the cluster.

Go to EC2 > Security Groups and click on "Create security group"

Set a name such as "MyAutomatorEFS".

Select Type of "NFS" and then select Custom and then the security group that was created in the prior step for the ECS cluster. Click "Create security group".

Note the security group ID for the next step. In this case, it is sgr-089fea5e4738f3898

(6) Create two Elastic File System volumes

At present, the Automator service needs access to two different folders. In this example setup, we are creating one volume to store the SSL certificate and SSL passphrase files. The second volume stores the property file for the Automator service. These 3 files are in your Keeper record.

Go to AWS > Elastic File System and click Create file system

Call it "automator_config" and click Create

Again, go to Elastic File System and click Create file system. Call this one automator_settings and click Create.

Note the File system IDs displayed. These IDs (e.g. fs-xxx) will be used in the ECS task definition.

After a minute, the 2 filesystems will be available. Click on each one and then select the "Network" tab then click on "Manage".

Change the security group for each subnet to the one created in the above step (e.g. "MyAutomatorEFS") and click Save. Make this network change to both filesystems that were created.

(7) Create Elastic Container Service Cluster

Navigate to the Amazon Elastic Container Service.

Select "Create cluster" and assign the cluster name and VPC. In this example we are using the default "AWS Fargate (serverless)" infrastructure option.

The Default namespace can be called "automator"
The "Infrastructure" is set to AWS Fargate (serverless)
Click Create

(8) Create ECS Task Definition

In your favorite text editor, copy the below JSON task definition file and save it.

Make the following changes to the JSON file:

Change the XXXCONFIGXXX value to a base64 config from Keeper Secrets Manager created in the beginning of this guide
Change the 3 instances of "XXXXX" to the Record UID containing the SSL certificate, SSL certificate password and settings file in your vault shared folder which KSM is accessing.
Change the two File system IDs (fs-XXX) to yours from the above steps

Next, go to Elastic Container Service > Task definitions > Create Task from JSON

Remove the existing JSON and copy-paste the contents of the JSON file above into the box, then click Create.

This task definition can be modified according to your instance CPU/Memory requirements.

(9) Upload SSL Cert to AWS Certificate Manager

In order for an application load balancer in AWS to serve requests for Automator, the SSL certificate must be managed by the AWS Certificate Manager.

Go to AWS Certificate Manager and Click on Import

On your workstation, we need to convert the SSL certificate (.pfx) file to a PEM-encoded certificate body, PEM-encoded private key and PEM-encoded certificate chain.

Since you already have the .pfx file, this can be done using the below openssl commands:

Download the ssl-certificate.pfx file and the certificate password locally to your workstation and enter the below commands:

Generate the PEM-encoded certificate body

Generate the PEM-encoded private key

Generate the PEM-encoded certificate chain

Copy the contents of the 3 files into the screen, e.g.

(10) Create a Target Group

Go to EC2 > Target Groups and click Create target group

Select "IP Addresses" as the target type
Enter the Target group name of "automatortargetgroup" or whatever you prefer
Select HTTPS Protocol with Port 443
Select the VPC which contains the ECS cluster

(11) Create Application Load Balancer (ALB)

Go to EC2 > Load balancers > Create load balancer

Select Application Load Balancer > Create

Assign name such as "automatornalb" or whatever you prefer
Scheme is "Internet-facing"
IP address type: IPv4
In the Network Mapping section, select the VPC and the subnets which will host the ECS service.

(12) Create ECS Service

Go to Elastic Container Service > Task definitions > Select the task created in Step 8.

From this Task definition, click on Deploy > Create Service

Select Existing cluster of "automator"
Assign Service name of "automatorservice" or whatever name you prefer
Important: For the number of Desired tasks, set this to 1 for right now. After configuration, we will increase to the number of tasks you would like to have running.

After a few minutes, the service should start up.

(13) Update DNS

Assuming that the DNS name is hosted and managed by Route53:

Go to Route53 > Create or Edit record

Create an A-record
Set as "Alias"
Route traffic to "Alias to Application and Classic Load Balancer"
Select AWS Region

The next step is to configure Automator using Keeper Commander while only having one task running.

(14) Install Keeper Commander

At this point, the service is running but it is not able to communicate with Keeper yet.

(15) Initialize with Commander

The Node Name (in this case "Azure Cloud") comes from the Admin Console UI as seen below.

The output of the command will display the Automator settings, including metadata from the identity provider.

Run the "automator edit" command as displayed below, which sets the URL and also sets up the skills (team, team_for_user and device).

Next we exchange keys: The enterprise private key encrypted with the Automator public key is provided to Automator:

Initialize the Automator with the new configuration

Enable the service

At this point, the configuration is complete.

For automated health checks, you can use the below URL:

https://<server>/health

Example curl command:

In this example setup, the load balancer will be sending health checks to the target instances.

(16) Testing the User Experience

The easiest way to test is to open an incognito mode window to the Keeper Web Vault and login with SSO Cloud. You will not be prompted for device approval.

Assuming that the approval worked, you can now increase the number of tasks running.