LDAP authentication | Strata Docs

Overview

Maverics requires the following information for LDAP authentication providers.

Field	Description
Name	A friendly name for your LDAP service.
URL	The URL of the LDAP server that Maverics connects with.
Service Account Username	The username used to connect to the LDAP server.
Service Account Password	The password used to connect to the LDAP server.
Base DN	Specifies the location in which to perform the LDAP search.
OUD Search Key	Key to filter on during query and bind operations.
Authentication Search Scope Optional	Provide the attribute you want to use for looking up user and group data. You can select from baseObject, singleLevel, or wholeSubtree.
Login URL Optional	Set a custom endpoint for posting the user's credentials. If unset, the form is will be submitted to a default location of /.ldap-login. Using the URL When specifying a Login URL, use absolute (full) URL including scheme, hostname, and path to ensure status requests are routed correctly. Always specify custom loginURL value if the Route Pattern in a Proxy app includes a hostname. For example, if the Route Pattern is defined as follows: - api.example.com Then the loginURL value might be: loginURL: https://api.example.com/login
Custom Login HTML Optional	Present a custom page to prompt the user for authentication. It should contain the file system location of an HTML page. If the value is unset a default login page will be used.
CA Optional	The path to your certificate authority when using self signed certs.

Custom Login and Localization

Click the Edit button in the Template and Assets section to define a custom login page and configure localization options. We recommend downloading and trying our sample files to test with this feature:

By uploading a template file, the Orchestrator delivers a custom HTML page stored in the filesystem. The Orchestrator uses Go Templates to provide the necessary data that will be rendered.

Select Upload from the Method dropdown menu, and click the Upload button to select the template file from your system. See our ldap-login.html example template for reference.

Methods for Parsing Language

This is an optional setting to customize which attributes of the request are used to parse the language code inputs. The ability to specify multiple parsers are ordered by preference.

All parsers are combined in order, and the best language match will be returned.

The Type field must be set to either http.request.header or http.request.query.
The Name field must be set to the name of the header or query parameter to be used.

Localizations

This list defines your translations and their corresponding ordering. The order of the localizations is important and must be set in order of preference. When no match is found the default localization will be rendered.

Missing localization values are resolved by the template using the empty string. It is important to note that missing localization fields may negatively impact the user experience.

The Locale field must be set to the BCP 47 language tag.
Select Upload from the Method dropdown menu, and click the Upload button to select the JSON file containing the localized values.

Download our en.json and fr.json sample localization files for reference. When configured correctly, the login page will appear as follows:

Identity Service Health Monitoring

Identity Service Health Monitoring is a feature used as part of Identity Continuity and is available for OIDC, SAML, and LDAP identity services. When enabled, this feature allows the orchestrator to continuously poll the identity service and trigger an alert if it can't be reached. In addition, you can create a manual failover mechanism for break-glass scenarios with the custom health check endpoint capability.

You will need to configure Identity Service Health Monitoring for each identity service used in your continuity strategy.

When this feature is enabled, the following fields can be configured:

Name	Description	Example
Polling Frequency	The interval between each health check of the identity service. Can be set in seconds, minutes, or hours.	`30s`
Timeout	The maximum wait time for a response. Can be set in seconds, minutes, or hours.	`5s`
Failover Threshold	The number of consecutive negative (down) health check results to trigger a failover.	4
Fallback Threshold	The number of consecutive positive (up) health check results to trigger a fallback.	4
Custom Health Check	Enabling this allows you to override the behavior of monitoring IDP availability. This can be used use custom signals for IDP health or for a break-glass scenario to manually trigger failover and fallback behaviors.
Custom Health Check Endpoint	The endpoint to use for the custom health check. The value must be a fully qualified URL.	`https://example.com/health`
Expected Status Codes	(Optional) The HTTP status codes that the custom health check returns to be considered healthy.	`200, 201`
Response Body Matcher	(Optional) A matcher that verifies the expected value in the response body of a health check.	`'"status": "up"'`