Authentication Backends

Configure SQL, LDAP, SAML 2.0, and OpenID Connect authentication drivers for NxtSight Identity.

Overview

NxtSight Identity supports multiple authentication drivers that can be combined within the same deployment. Each domain can use a different backend, allowing you to integrate enterprise LDAP directories or federated identity providers alongside local SQL accounts.

Administrator Access Required — This operation requires the admin role. Contact your NxtSight administrator if you do not have sufficient permissions.

---

Backend Comparison

Backend	Use Case	Configuration
SQL	Default. Local users stored in MariaDB. Zero external dependencies.	Built-in; no additional config required.
LDAP	Enterprise directory integration. Users and groups sourced from Active Directory or OpenLDAP.	Configured per-domain via nxtDeploy globals.
SAML 2.0	SSO with corporate IdPs (Okta, Azure AD, ADFS).	Requires mod_shib and federation mapping rules.
OIDC	Modern SSO via OAuth 2.0 / OpenID Connect providers.	Requires mod_auth_openidc and attribute mapping.

---

SQL Backend (Default)

The SQL backend is active by default and requires no additional configuration. All user accounts created through the Dashboard or CLI are stored in MariaDB.

Verify the SQL backend is active

openstack --os-cloud admin domain show Default -f json | grep -i driver

The SQL backend is appropriate for most deployments. Use LDAP or federation only when integrating with an existing enterprise directory.

---

LDAP Integration

LDAP integration sources users and groups from an external directory. NxtSight Identity connects in read-only mode — user creation and password changes must happen in the directory, not in NxtSight.

1. Configure LDAP in nxtDeploy globals

   Set the following in your deployment globals via nxtDeploy:

   LDAP configuration in deployment globals

   keystone_ldap:
     url: ldap://ldap.example.com
     user: cn=NxtSight-svc,dc=example,dc=com
     password: "{{ ldap_bind_password }}"
     suffix: dc=example,dc=com
     user_tree_dn: ou=Users,dc=example,dc=com
     group_tree_dn: ou=Groups,dc=example,dc=com
     user_id_attribute: sAMAccountName
     user_name_attribute: sAMAccountName
     user_mail_attribute: mail
     group_id_attribute: cn
     group_name_attribute: cn
     group_member_attribute: member
   
2. Deploy the configuration

   Apply LDAP configuration

   nxtVirt-ansible deploy --tags keystone
   
3. Verify LDAP connectivity

   Test the LDAP connection from the Identity API node:

   Test LDAP connectivity

   ldapsearch -x -H ldap://ldap.example.com \
     -D "cn=NxtSight-svc,dc=example,dc=com" \
     -w "$LDAP_PASSWORD" \
     -b "ou=Users,dc=example,dc=com" \
     "(sAMAccountName=alice)"
   

   User record is returned — LDAP is reachable and the bind account has read access.

LDAP integration is read-only. User management (password resets, account creation) must be performed in the directory, not through the NxtSight Dashboard or CLI.

---

SAML 2.0 Federation

SAML 2.0 federation enables SSO with corporate identity providers. Users authenticate at the IdP and receive NxtSight tokens without a local password.

1. Configure the identity provider in your IdP

   Register NxtSight as a service provider in your IdP. Provide the NxtSight SAML metadata URL:

   https://api.<your-domain>:5000/v3/OS-FEDERATION/identity_providers/<IDP_ID>/protocols/saml2/auth
   
2. Register the IdP in NxtSight

   Create identity provider

   openstack identity provider create \
     --remote-id https://idp.example.com/sso/saml \
     corporate-idp
   
3. Create attribute mapping

   Define how IdP attributes map to NxtSight groups and projects:

   Create mapping rules

   openstack mapping create \
     --rules mapping-rules.json \
     corporate-mapping
   

   Example mapping rules:

   mapping-rules.json

   [
     {
       "local": [
         {"user": {"name": "{0}"}},
         {"group": {"id": "<NxtSight_GROUP_ID>"}}
       ],
       "remote": [
         {"type": "ADFS_LOGIN"},
         {"type": "memberOf", "any_one_of": ["CN=NxtSight-users,OU=Groups,DC=example,DC=com"]}
       ]
     }
   ]
   
4. Create the federation protocol

   Link IdP, mapping, and protocol

   openstack federation protocol create saml2 \
     --identity-provider corporate-idp \
     --mapping corporate-mapping
   

   Federation protocol is created. IdP users can now authenticate via SAML SSO.

---

OpenID Connect

OIDC federation uses OAuth 2.0 bearer tokens from a compatible provider (Google, Azure AD, Okta, Keycloak).

Create OIDC identity provider

openstack identity provider create \
  --remote-id https://accounts.google.com \
  google-oidc

Create OIDC mapping

openstack mapping create \
  --rules oidc-mapping-rules.json \
  google-mapping

Create OIDC federation protocol

openstack federation protocol create openid \
  --identity-provider google-oidc \
  --mapping google-mapping

---

Next Steps

Domain Management

Assign different authentication backends to different domains.

Federation

Advanced federation configuration — mapping rules and attribute assertions.

Security Hardening

Secure your authentication backends with encryption and access controls.

Admin Troubleshooting

Debug LDAP connectivity and federation authentication issues.