> ## Documentation Index
> Fetch the complete documentation index at: https://arize-ax.mintlify.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# SAML Configuration
> Configure SAML authentication for your Arize AX account, including metadata setup, role mappings, and user provisioning settings
Only available for AX Enterprise accounts.
Account admins can configure SAML settings directly from the **SAML Configuration** tab in the **Account Settings** page.
# Configuration
When creating or editing existing entries, you'll use a form with two tabs: General Configuration and Role Mapping. For new entries, you will be guided through the configuration process.
## General Configuration
### 1. Email Domains Field
Add as many email domains that share the same configuration. An email domain must be unique among all IdP entries in the system (except they can overlap and override existing file-based entries).
**Validation status:**
* **SaaS (Arize employee)**: Email domains are considered validated
* **SaaS (Customer admin)**: Email domains are unvalidated until an Arize employee edits the entry, unless the domain is also found in a file-based entry
* **File-based entries**: Overlapping domains are considered validated
Due to caching, changes to email domain information may take up to a minute to take effect.
### 2. Metadata
Enter either the **Metadata URL** (preferred) or **Metadata XML** data.
The Metadata URL is an option to automatically fetch the Metadata XML from your IdP. Alternatively, you can provide the Metadata XML directly. This information is available in the SAML configuration settings of your IdP.
Due to caching, changes to metadata information may take up to a minute to take effect.
### 3. User Settings
Due to caching, changes to user settings may take up to a minute to take effect.
#### Allow Only SAML Logins
If enabled, users can only log in via SAML. This prevents anyone from logging in with a username/password combination.
If you enable this setting, ensure you have a SAML-mapped account administrator who can access the SAML configuration page. Otherwise, you may need to contact Arize support to disable this setting if you need to troubleshoot access issues.
#### Sync Permissions on Each Login
When enabled, the user's permissions are synced on every SAML login.
**Important**: Only enable permission syncing **AFTER** you've completed role mapping. If you turn sync on without role mappings, the outcome depends on the `Allow login to default Organization and Space` setting:
* If enabled: Each user will be reset to the default organization and space with the roles listed in the form
* If disabled: The login will fail
You will not be able to manage user access from other Arize AX UI screens if sync is enabled, as permissions will be reset on every login.
**Timing considerations**: After making changes to role mappings, a user's next SAML login might take up to 24 hours to reflect the changes due to access and refresh tokens keeping their last login session alive. If you want changes to role mappings to take effect immediately, users may need to log out to force a SAML login.
#### Allow Login to Default Organization and Space
When enabled:
* If a new user logs in via SAML and does not match any role mappings, they are added as members of the default organization and space with the roles listed in this section
* These values are also used if `Allow only SAML Logins` is enabled and there is no role mapping match
## Role Mappings
Role mappings are optional but recommended for automated user provisioning and access control. During the SAML protocol exchange, your Identity Provider (IdP, e.g., Okta) can be configured to send assertions about the user. These assertions can be used to determine how a new user should be created or how an existing user should be updated (if `Sync permissions on each login` is enabled).
### How Role Mappings Work
The assertion's attributes (key/value pairs) can be matched against your role mappings to determine:
1. **Account admin status**: Whether the user should be an account administrator
2. **Organization and space placement**: Which organization and optionally which spaces the user should be placed into
3. **Space role assignment**: Which role to assign per space — either a built-in space role (Admin, Member, Read-only, Annotator) or a [custom role](/ax/security-and-settings/sso-and-rbac/custom-roles) with fine-grained permissions
If there are **no attribute matches**, the behavior depends on the `Allow login to default Organization and Space` setting:
* If **Enabled**: Default organization and space are used
* If **Disabled**: Login will be rejected
If **more than one attribute key/value pair** is present in an individual role mapping, **all** those attributes must match the incoming assertion's equivalent key/value settings.
### Configuring a Role Mapping
Each role mapping consists of:
1. **SAML Attributes** — One or more key/value pairs that must match the incoming SAML assertion. For example, `Department = Engineering`.
2. **Account Admin toggle** — If enabled, matching users are granted Account Admin access. When this is on, organization and space assignments are not needed.
3. **Organization and Role** — Select which organization the user should be placed into and their organization-level role (Admin, Member, or Read-only).
4. **Space Assignments** (optional) — For non-admin organization roles, you can add one or more space assignments. For each space, select a role from the dropdown:
* **Built-in roles**: Admin, Member, Read-only, or Annotator
* **Custom roles**: Any [custom role](/ax/security-and-settings/sso-and-rbac/custom-roles) defined in your account appears in the same dropdown, allowing you to assign fine-grained permissions per space during provisioning
You can create multiple role mappings to handle different teams or departments. For example, one mapping for `Department = Engineering` that assigns a custom "Dataset Manager" role on Space A, and another for `Department = QA` that assigns a "Project Viewer" role on Space B.
When using custom roles in SAML role mappings with `Sync permissions on each login` enabled, the user's custom role bindings will be updated on every login to match the mapping. Any manual role binding changes made between logins will be overwritten.
# Caching
Database entries are cached in the backend application to reduce database calls. If no action has occurred on an entry recently, changes take effect immediately. The times below are the worst-case delays for changes to take effect:
* **Changing the metadata XML, metadata URL, or email domain fields**: 1 minute
* **Changing the role mappings or user settings**: 1 minute
For additional support, join the [Arize Community Slack](https://join.slack.com/t/arize-ai/shared_invite/zt-1pxv6hdvk-eK0IC2f7qwq~BG_8lj~tfw).