Configuration
Administrator guide for configuring Access Hub, including Global Identity Provider setup, Lifecycle Management integration, and identity mapping.
Configuration guide for Access Hub, including Global Identity Provider setup, Lifecycle Management integration, and catalog functionality.
Overview
Access Hub provides self-service access management through two main experiences:
- My Access & My Team: View existing access and team relationships 
- Catalog: Request new access through pre-approved Access Profiles 
Configuration requires identifying users, establishing manager relationships, and mapping identities across your SSO, HR, and Veza systems. See Prerequisites for requirements by feature.
Prerequisites
Before configuring Access Hub, ensure you have the necessary licenses, permissions, and integrations in place. Missing any of these requirements will prevent Access Hub from functioning correctly.
For all Access Hub features
- Access Hub license enabled in your Veza tenant 
- Veza administrator account with appropriate permissions (see Required Permissions below) 
- API token - most configuration steps use Veza's REST API rather than the UI 
- Single Sign-On (SSO) configured and functional - Access Hub relies on SSO to authenticate users and establish their identity. Test SSO authentication before proceeding. 
Required Permissions
Access Hub configuration and usage requires different permission levels depending on the operation:
Configuration Permissions (API-based setup):
To configure Global Identity Provider Settings (Step 1), you need ONE of the following:
- modify_idp_configurationpermission on the root team
- adminrole
- access_reviews_adminrole
Read-Only Access to Configuration:
To view Global Identity Provider Settings, you need ONE of the following roles:
- admin
- access_reviews_admin
- operator
- access_reviewer
- viewer
- reassigner
- watcher
- access_reviews_monitor
- nhi_security_admin
Or the read_configuration permission on the root team.
For My Access and My Team views
These views allow users to see their current access and team members who report to them:
- Identity Provider integration (Okta, Azure AD, etc.) configured in Veza - provides the source of user identity and organizational data 
- Manager relationships populated in your identity system - enables the My Team view and approval workflows 
- Global IdP Settings configured (via API) - tells Veza which identity source to trust as authoritative 
- Veza integration enabled - makes local Veza user accounts visible in the authorization graph for identity mapping 
For Access Hub Catalog
The catalog enables self-service access requests. This requires matching user identities from SSO with employee records from your HR system:
Catalog functionality requires all items from "My Access and My Team views" above, plus:
- Lifecycle Management license enabled - catalog functionality is built on LCM 
- HR system or identity source integration configured - provides employee data (name, department, manager, employment status) 
- Lifecycle Management identities created from HR data - establishes employee records that can be mapped to Veza users 
- Access Profiles configured and assigned to users - defines what access can be requested 
- Access Requests enabled in Lifecycle Management settings - activates the request workflow 
Identity Mapping Configuration Points
Access Hub requires consistent identity mapping across systems using the same identifier type (employee ID or email) everywhere.
Global IdP Settings
Identify authenticated users and managers
My Access, My Team
/api/private/workflows/access/global_settings/idp_settings
IdP Integration Mapping
Map IdP users to Veza Local Users
My Access, My Team, Catalog
Integration Settings UI
LCM Identity Settings
Map Veza users to LCM identities
Catalog
Lifecycle Management > Settings
HR Integration
Source LCM identities from HR system
Catalog
Integration Settings UI
Example consistent configuration: If your Global IdP Settings use employee_id, then your LCM Identity Settings, IdP Integration, and HR Integration must all also use employee ID as the matching key.
Architecture and Identity Flow
This diagram shows how identity systems connect to enable Access Hub:
Step 1: Configure Global Identity Provider Settings
Global IdP Settings specify which identity source Veza queries for user data, manager relationships, and organizational hierarchy. This configuration enables the My Access and My Team views.
Use your production SSO provider ID, not test or development instances.
1.1 Retrieve your Authorization Provider ID
The Global IdP configuration requires an auth_provider_id from your SSO configuration. This ID must be retrieved via API.
API Call: GET /api/private/auth_providers
curl -H "Authorization: Bearer YOUR_API_TOKEN" \
  https://your-tenant.veza.com/api/private/auth_providersResponse Example:
{
  "auth_providers": [
    {
      "id": "cf9bab40-4e48-4afc-a310-acfdad416233",
      "name": "SAML SSO",
      "auth_provider_type": 2,
      "enabled": true,
      "is_configurable": true,
      "created_at": "2024-01-15T10:30:00Z",
      "updated_at": "2024-01-15T10:30:00Z"
    },
    {
      "id": "8a7e3c9f-2b5d-4f1e-9c3a-7d8b4e6f1a2c",
      "name": "Local Authentication",
      "auth_provider_type": 1,
      "enabled": true,
      "is_configurable": false,
      "created_at": "2024-01-01T00:00:00Z",
      "updated_at": "2024-01-01T00:00:00Z"
    },
    {
      "id": "b3d4e5f6-1a2b-3c4d-5e6f-7a8b9c0d1e2f",
      "name": "OIDC SSO",
      "auth_provider_type": 3,
      "enabled": false,
      "is_configurable": true,
      "created_at": "2024-02-10T14:20:00Z",
      "updated_at": "2024-02-10T14:20:00Z"
    }
  ]
}Response Fields:
id
The unique identifier for this auth provider - use this value as auth_provider_id in Global IdP Settings
name
Display name for the authentication provider
auth_provider_type
Integer indicating the provider type (see Auth Provider Type Values below)
enabled
Whether this provider is currently active for user authentication
is_configurable
Whether this provider can be modified through the UI
created_at
ISO 8601 timestamp of when the provider was created
updated_at
ISO 8601 timestamp of the last configuration update
Selecting the Correct Provider:
For Access Hub configuration, select the provider where:
- enabled: true- The provider is actively authenticating users
- auth_provider_type: 2(SAML) or- 3(OIDC/SSO) - Matches your SSO configuration
- The - namematches your SSO provider in Administration > Sign-in Settings
Important: Do not use providers with auth_provider_type: 1 (Local Authentication) or auth_provider_type: 4 (Support Access) for Access Hub configuration. These are internal authentication methods and should not be configured as Global IdP.
Auth Provider Type Values:
The auth_provider_type field returns an integer representing the authentication provider category:
- 1:- LOCAL_AUTH_PROVIDER- Local username/password authentication
- 2:- SAML_AUTH_PROVIDER- SAML-based SSO (includes local_saml and auth0_saml implementations)
- 3:- SSO_AUTH_PROVIDER- Single Sign-On via OpenID Connect (OIDC), Dex, or other SSO implementations
- 4:- SUPPORT_AUTH_PROVIDER- Support user access
- 5:- SERVICE_ACCOUNT_AUTH_PROVIDER- Service account authentication
- 6:- TOKEN_JWT_AUTH_PROVIDER- JWT token-based authentication
Note: For SAML-based SSO configurations, look for providers with auth_provider_type: 2 and enabled: true. For OIDC-based SSO, look for auth_provider_type: 3.
For more details on SSO configuration, see Sign-in Settings.
1.2 Gather Identity Provider Information
Identify how users and managers are represented in your identity system within Veza. Attribute names vary between providers (Okta, Azure AD, Workday, etc.).
Using Veza Query Builder or the Graph, identify the following:
- User Type: The graph entity type for your users (e.g., OktaUser, AzureADUser, WorkdayWorker) 
- Instance ID: The unique identifier for your IdP instance: - For Okta: Your Okta domain (e.g., dev-5150036.okta.com) 
- For Azure AD: Your tenant ID (e.g., d5d23474-d857-4e12-bf68-75d638867e93) 
- For Workday: The datasource ID from the integration 
 
- User Identity Property: The unique identifier for users - Recommended: - employee_id(more reliable than email)
- Alternative: - email
- Custom: Any unique attribute discovered by Veza 
 
- Manager Identity Property: The attribute containing manager references (must use the same identifier type as user_identity_property) - Examples: - manager_employee_id,- manager_email,- managers
 
1.3 Configure Global IdP Settings
API Call: PUT /api/private/workflows/access/global_settings/idp_settings
Request Body:
{
  "value": {
    "enabled": true,
    "idp": {
      "auth_provider_id": "cf9bab40-4e48-4afc-a310-acfdad416233",
      "user_type": "WorkdayWorker",
      "instance_id": "your-workday-datasource-id",
      "user_identity_property": "employee_id",
      "instance_id_property": "datasource_id",
      "manager_identity_property": "manager_employee_id",
      "active_user_conditions": {
        "fn": "EQ",
        "property": "is_active",
        "value": true
      }
    }
  }
}enabled
Set true to enable the provider as a Global IdP
auth_provider_id
Internal UID for the single sign-on provider instance (from Step 1.1)
user_type
Graph entity type to search for users, such as OktaUser or WorkdayWorker
instance_id
The UID for a provider in the data catalog
user_identity_property
Unique entity property used to identify the IdP user
instance_id_property
The user entity property used to identify the IdP instance (typically datasource_id)
manager_identity_property
The user entity property used to identify the manager
idp_type
Optional field that specifies the application type for the identity provider (e.g., "okta", "azure_ad"). This field is typically set automatically based on the user_type and is used for internal classification.
active_user_conditions
Optional filter for identifying active users
Example Configurations
Okta Configuration:
{
  "value": {
    "enabled": true,
    "idp": {
      "auth_provider_id": "your-auth-provider-id",
      "user_type": "OktaUser",
      "instance_id": "dev-5150036.okta.com",
      "user_identity_property": "employee_id",
      "instance_id_property": "datasource_id",
      "manager_identity_property": "manager_employee_id"
    }
  }
}Azure AD Configuration:
{
  "value": {
    "enabled": true,
    "idp": {
      "auth_provider_id": "your-auth-provider-id",
      "user_type": "AzureADUser",
      "instance_id": "d5d23474-d857-4e12-bf68-75d638867e93",
      "user_identity_property": "employee_id",
      "instance_id_property": "datasource_id",
      "manager_identity_property": "manager_employee_id"
    }
  }
}Multiple Active User Conditions:
The active_user_conditions field accepts an array for complex filtering:
{
  "active_user_conditions": [
    {
      "fn": "EQ",
      "property": "is_active",
      "value": true
    },
    {
      "fn": "NE",
      "property": "status",
      "value": "terminated"
    }
  ]
}Advanced Configuration
For organizations with complex identity structures requiring manager lookups across multiple identity providers or secondary sources of identity, see Alternate Manager Lookup for full API documentation and additional configuration options using the alternate_manager_lookup_settings parameter.
Verification
To verify your current configuration:
curl -H "Authorization: Bearer YOUR_API_TOKEN" \
  https://your-tenant.veza.com/api/private/workflows/access/global_settings/idp_settingsStep 2: Enable Veza Integration
The Veza integration makes your local user accounts (created via SSO) visible as entities in the authorization graph, enabling identity mapping between Veza users and external identity sources.
To enable the Veza integration:
- Navigate to Integrations > Add Integration 
- Search for "Veza" and enable the integration 
- Important: Check the option to enable for Lifecycle Management and SCIM if using SCIM provisioning - this makes Veza users available as targets for LCM identity mapping 
- After enabling, verify that - Veza Local Userentities appear in Query Builder (schema type:- VezaUser)
For more information, see the Veza integration guide.
Step 3: Configure Lifecycle Management for Catalog Functionality
The Access Hub catalog requires Lifecycle Management identities to map Veza users to employee records from your HR system.
3.1 Create Lifecycle Management Policy
Create a basic Lifecycle Management policy to establish the identity mapping table:
- Navigate to Lifecycle Management > Policies 
- Create a new policy with your identity source (e.g., Workday) 
- Add a basic workflow that creates the identity mapping 
- Use a condition that won't trigger (e.g., - active = "placeholder") to create the identity table without executing workflows
- Publish the policy 
For detailed policy configuration, see Lifecycle Management Policies.
3.2 Configure Lifecycle Management Identity Settings
Enable identity mapping for the catalog functionality:
- Go to Lifecycle Management > Settings > Identity Settings 
- Use the dropdown to choose a Mapping Type: - Email 
- Employee ID 
 
This mapping connects Veza local users (created via SSO) to Lifecycle Management identities (created from HR data).
3.3 Enable Access Requests
Enable the access request functionality:
- Go to Lifecycle Management > Settings > Access Request Settings 
- Toggle Enable Requests 
For more information about managing access requests, see the Lifecycle Management documentation.
Step 4: Configure Integration Identity Mappings
Identity mapping ensures users are consistently identified across integrated systems, connecting your Identity Provider users to Veza local accounts and Lifecycle Management identities.
Security: Misconfigured mappings can allow users to access another person's information. Use unique identifiers (employee_id recommended over email) and test in a non-production environment first.
4.1 Configure Identity Provider to Veza Local User Mapping
Map authenticated users from your IdP (Okta, Azure AD, etc.) to Veza local user accounts:
- Navigate to Integrations and select your Identity Provider (Okta, Azure AD, etc.) 
- Click Edit to modify the integration settings 
- Scroll to the Mapping Configuration section 
- If no mapping exists, click Add Mapping Configuration: - Use Email By Default: Enable if your users authenticate with email addresses 
- Mapping Mode: Select Users (not Groups) 
- Destination Data Source Type: Select Veza from the dropdown 
 
- Configure Property Matchers based on your authentication method: - For email-based authentication: - Source Property: Email 
- Destination Property: Email 
 
- For employee ID-based authentication: - Source Property: Custom Property (enter your employee ID field name) 
- Destination Property: Unique ID 
 
 
- Apply transformations if needed: - Ignore Domain: Enable to match users regardless of email domain differences 
- Ignore Special Characters: Enable to handle variations in formatting 
 
- Click Save Configuration 
4.2 Configure HR System to Lifecycle Management Identity Mapping
Your HR system integration must create Lifecycle Management identities from employee records. This mapping is typically established automatically when you create a Lifecycle Management policy using your HR system as the identity source.
- Navigate to Integrations and select your HR system (Workday, BambooHR, etc.) 
- Click Edit to modify the integration settings 
- Verify Custom Properties includes any required fields: - Employee ID 
- Manager relationships 
- Department/organizational data 
 
- In the Mapping Configuration section: - Ensure mapping is configured to create Lifecycle Management identities 
- Verify the identity property (employee ID or email) matches your Global IdP configuration 
- Confirm manager relationship fields are properly mapped 
 
Example Configuration:
- Global IdP Settings: - "user_identity_property": "employee_id"
- Lifecycle Management Settings: Employee ID mapping type 
- Okta Integration: Custom Property - employee_id→ Unique ID
- Workday Integration: Employee ID field properly extracted and mapped 
Troubleshooting
Verification Steps
Test your configuration by checking the following:
- Global IdP Settings: Users from your IdP appear correctly in Access Hub 
- SSO Integration: Users can authenticate and access the platform 
- Identity Mapping: Users see their correct access in My Access view 
- Manager Relationships: Managers can see their team members in My Team view 
- Catalog Access: Users see appropriate Access Profiles in the Catalog 
Common Issues
Issue: Users see duplicate identities or incorrect access
- Verify - auth_provider_idmatches the correct SSO provider from- /api/private/auth_providers
- Check that - user_identity_propertyis consistently configured across all systems
- Ensure identity mappings use the same identifier type (employee ID or email) 
Issue: Managers cannot see their team members
- Verify manager relationships are populated in your identity system 
- Check that - manager_identity_propertyis correctly configured
Issue: Catalog is empty or Access Profiles don't appear
- Verify Lifecycle Management license is enabled 
- Check that Access Requests are enabled in Lifecycle Management Settings 
- Ensure users have corresponding Lifecycle Management identities 
- Verify Access Profiles are assigned to user identities 
Related Documentation
Configuration Guides
Lifecycle Management
Integration Setup
API Documentation
Access Hub Features
Last updated
Was this helpful?
