The Strivacity Directory Connector 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 Directory Connector 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 Directory Connector is containerized for deployment in Kubernetes, Docker, or similar environments. Deployment requires a customer to implement the Directory Connector with communications access to the on-prem user store.

📘

If you require the Directory Connector container image, please inquire with support.

This image is different than the Login Gateway 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 Directory Connector can be fully set up.

Configure the Strivacity identity store

Configuration

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

📘

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

• Synchronization options determine the behavior of the application when authenticating and the Directory Connector is not responding.
  • Do not store passwords locally: Authenticate users by verifying passwords directly with the remote directory. No passwords are saved locally.
  • Cache passwords: Saves passwords locally as a backup. If the remote directory is unavailable, the cached password will be used for authentication.
  • Sync password changes from accounts in the local directory to the remote directory account: Updates passwords in the remote directory whenever they are changed in the local identity store.

🚧

Password changes for synced accounts

If an account is snyced from an external directory, local password changes are only allowed when both of the following conditions are met:

• The Connector is enabled.
• Password synchronization is enabled. (Password caching alone does not allow changes.)

If the Connector is disabled or synchronization is not enabled, attempts to change the password will result in an error.

Non-synced local accounts are not affected by these settings.

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

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 Directory Connector to the cloud are in a flat structure.

📘

The attribute paths from the Directory Connector 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 Directory Connector 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 Directory Connector.