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-premises store to securely process authentication requests from the cloud, eliminating the need to open firewall ports or allow other Internet traffic.

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 the 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 access to the on-premises user store for communications.

📘

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:

Configurable attributes in the connector YAML

The Directory Connector YAML supports only three fields for direct attribute mapping.

Example configuration from the values.yaml file in Strivacity’s Helm chart:

connector:
  ldap:
    uniqueIdAttributeName: uid
    emailAttributeName: mail
    userNameAttributeName: username

• uniqueIdAttributeName: A unique identifier for the customer account in the directory.
• emailAttributeName: The field that maps to the customer's email address.
• userNameAttributeName: The field that maps to the customer's username (if usernames are enabled for authentication).

📘

Only the username, email, and unique identifier fields can be mapped in the Directory Connector YAML. All other attribute mappings must be configured via the Admin Console’s Remote path setting for each attribute (as shown above). Changes made in the connector YAML for other fields won’t have any effect. See Edit attributes - General settings for more details on configuring remote paths.

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 (for example, 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.