User Provisioning | Anjana Data Documentación

While Authentication verifies a user's identity to grant access ("Who are you?"), Provisioning (or Synchronization) is the process by which Anjana Data obtains and updates user information (Name, Email, Phone, etc.) by connecting directly to the Corporate Directory.

This process is essential for:

Source of Truth: Keeping the local database aligned with the corporate directory.
Productivity: Assigning roles or responsibilities to users who have not yet logged in.
Metadata: Having up-to-date contact information available for notifications and workflows.

How does it work?

Unlike Login (which happens in real time), Provisioning is a background process.

Connection: Anjana Data connects to the provider's administrative management API.
Extraction: It downloads the full list of users assigned to the application.
Normalization: It converts each cloud's proprietary data into Anjana Data's standard format.
Persistence: It creates or updates the records in Anjana Data's local database.

Note: At runtime (login, user search), Anjana Data does not query the external APIs; it queries its local database, which has been populated by this process.

Supported providers

Anjana supports native synchronization with the following providers. Note that the credentials required for provisioning (management APIs) are usually different from those used for authentication (Login).

Provider	Underlying technology	Key requirements
Microsoft Azure AD	Microsoft Graph API	App Registration with `User.Read.All` permissions
Google Workspace	Google Directory API	Service Account with Domain-wide Delegation
AWS IAM Identity Center	AWS Identity Store API	Access/Secret Keys with `identitystore:DescribeUser` permissions
AWS Cognito	Cognito Identity Provider API	IAM user with `cognito-idp:ListUsers` permissions
Auth0	Auth0 Management API (Jobs)	M2M application with `read:users` permissions
Okta	Okta Core API	Administration API Token (SSWS)
Keycloak	Keycloak Admin REST API	Confidential client with service account and `view-users` role in `realm-management`
LDAP / Active Directory	LDAPv3 protocol	Service user with read permissions (`bind`)

General configuration

Provisioning configuration (except LDAP) is centralized in the security.provisioning section of the application.yml file of the Zeus microservice.

This configuration is independent of the authentication section. You can configure multiple data sources to synchronize users.

YAML

security:
  # ===============================================
  # PROVISIONING SECTION (User Synchronization)
  # ===============================================
  provisioning:
    providers:
      # --- AWS Identity Center ---
      aws-iam-ic:
         proveedor-aws-sso:
           region: "eu-west-1"
           identity-store-id: "..."

      # --- AWS Cognito ---
      aws-cognito:
        proveedor-clientes:
          user-pool-id: "eu-west-1_xxxx"
          access-key: "..."

      # --- Auth0 ---
      auth0:
        proveedor-auth0:
          domain: "midominio.auth0.com"
          client-id: "..." # M2M App

      # --- Keycloak ---
      keycloak:
        keycloak-corp:
          server-url: "https://sso.mi-dominio.com"
          realm: "mi-realm"
          client-id: "anjana-provisioning"
          client-secret: "..."

      # --- Other providers ---
      # azure-graph: ...
      # google: ...
      # okta: ...

Exception: LDAP

Due to the nature of the LDAP protocol, authentication and provisioning configuration are done jointly in the security.authentication.ldap section. It does not require an entry in security.provisioning.

Custom field mapping (`field-mapping`)

Each provider exposes user data under its own API-specific names. Anjana automatically normalizes it into six standard fields:

Anjana Field	Description
`userName`	Unique login identifier. Primary key of the user in Anjana.
`email`	Email address.
`firstName`	First name.
`lastName`	Last name(s).
`phone`	Contact phone number.
`title`	Job title or position.

Each provider has a reasonable default mapping (documented in its specific guide). If your directory stores this data under different keys - for example, a custom Cognito attribute, an Okta Profile Editor field, or an extended Keycloak attribute - you can redefine the mapping using the field-mapping property under the provider configuration:

Each field accepts a list of keys in priority order.
Anjana uses the first non-empty value it finds.
You only need to include the fields you want to change; the rest continue to use the default mapping.

YAML

security:
  provisioning:
    providers:
      azure-graph:
        azure-prod:
          tenant-id: "..."
          field-mapping:
            user-name: ["mail"]                        # mail instead of userPrincipalName
            phone: ["businessPhones", "mobilePhone"]   # company → mobile (fallback)

See each provider's guide for the full list of available keys and the default mapping.

Provider-specific configuration guides

Select the appropriate guide to obtain the API credentials for your provider:

Microsoft Azure (Graph API)

Google Workspace

AWS IAM Identity Center

AWS Cognito

Okta

Auth0

Keycloak (Admin REST API)