Bridge for on-premises user stores

The Strivacity Bridge for on-premises user stores and directories facilitates support for legacy user identity stores (LDAP-capable products, database stores, etc.) when migrating from an on-premises solution to Strivacity, or when it is too complex to move authentication credentials directly to Strivacity.

The authentication bridge uses a direct connection to the on-premise store to securely process authentication requests from the cloud without the need to open firewall ports or other traffic from the Internet.

Capabilities

  • Query directories for users and validate users' credentials
  • Customize the attributes/fields used in the store for identifiers, email addresses, and more
  • Only send necessary information about the user to the cloud from the store
  • Multiple instances can be deployed for redundancy

How to set up

On-premises component

The Bridge is containerized for deployment in Kubernetes, Docker, or similar environments. Deployment requires a customer to implement the bridge with communications access to the on-prem user store.

📘

If you require the on-premise bridge container image, please inquire with support.

This image is different than the bridge image used for header-based authentication.

The on-premise container requires some local configuration to be able to communicate with the local user store and the Strivacity cloud. The identity store must be configured before the bridge can be fully set up.

Configure the Strivacity identity store

Configuration

When creating an Identity Store, simply enable the Connect to Strivacity Bridge for on-premises directories option. This will generate a client ID and secret used for the local configuration of the bridge.

📘

The Client ID and secret will not be generated until the identity store is saved.

  • Synchronization options_ determines the behavior of the application when authenticating and the bridge is not responding.
  • If Do not store passwords is chosen, the bridge must be up and communicating with Strivacity to allow authentications.
  • If Cache passwords is selected, then (if the user has authenticated recently) a user will be able to authenticate even if the bridge is unreachable.

The allowed Identifiers for this identity store (Username, Email, or both) also affect the behavior of the bridge. The bridge will search for identifiers in different fields in the on-premises directory based on the allowed identifiers configured.

Strivacity Bridge for on-premises directories Admin Console configuration settings

Strivacity Bridge for on-premises directories Admin Console configuration settings

Attributes

In addition to the username and email identifiers, other account attributes can be mapped into the identity store and updated as part of authentication.

These mappings are done in the Edit attributes interface. Currently, all attributes sent from the Bridge to the cloud are in a flat structure.

📘

The attribute paths from the bridge are dependent on the underlying local user store product and configuration.

For example, an Active Directory sn (which is the Last Name field) can be mapped to the Family Name field in the identity store by configuring the Remote Path field:

Setting up the on-premises component

The Strivacity Bridge requires several pieces of information to talk to Strivacity and to the user store. These configuration items are kept local to the on-premises environment to avoid unnecessary credentials being stored in the cloud.

The local configuration requires:

  • The client ID and client secret generated during the identity store creation
  • The Strivacity base URL of the customer (for example, mybrand.strivacity.com)
  • Connection information for the user store. This will include credentials for connecting to the local store, URLs/addresses of the store, etc.
  • Store-specific configuration (for example, DN information for LDAP-based stores)
  • The names of specific attributes
    • The attribute used for usernames (if usernames are enabled on the identity store for authentication)
    • The attribute used for email addresses (if email addresses are enabled on the identity store for authentication)
    • The unique identifier for a user. This could be the same as one of the above attributes (e.g. uid) but might be different. Strivacity will store a reference to this user based on this identifier.

📘

Strivacity support will provide detailed configuration instructions for using this information when setting up the bridge.