# Implementation and Core Concepts ### The IAM challenge Without automated lifecycle management, organizations face a fragmented identity and access management landscape. Multiple systems require manual coordination, leading to delays in provisioning, security gaps from orphaned accounts, and compliance risks. ![IAM framework before Veza showing manual processes and disconnected systems](/files/1hGT2AqQ6qui67CfvpGT) ### How Veza streamlines IAM Veza Lifecycle Management provides a unified platform that automates identity provisioning and de-provisioning across your entire technology stack. Changes in your HR system automatically trigger coordinated workflows across all connected applications, ensuring consistent access management throughout the employee lifecycle. ![IAM framework with Veza showing automated workflows and centralized management](/files/8QKQGuNPuzoy9tjill84) *** Before you begin creating draft [Policies](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md) for automating Lifecycle Management workflows, you should establish and document how employees in your organization are mapped to business roles, and corresponding birthright entitlements (default access permissions granted based on an employee's role) such as groups and roles in target applications. Implementing Veza Lifecycle Management will require: * Defining segmentation criteria in terms of **Business Roles** for identities in your organization. * Defining **Role Conditions** used in Lifecycle Management policies that Veza will use to match roles to identities, based on attributes from the source of identity. * Defining **Profiles** for each target application that will map **Business Roles** to application-specific entitlements. * Assigning **Profiles** to **Business Roles** to enable business rules. The topics in this document will help you structure your Lifecycle Management implementation, and establish foundations that you can use to simplify access management throughout the employee lifecycle. ### Planning Your Implementation #### Key considerations and requirements * Is a lifecycle management process defined for your organization? * If yes: Begin assessing your current policies for implementation with Veza Lifecycle Management. * If no: Work with application owners, HR administrators, and other stakeholders to establish protocols for granting and revoking access as employees join, depart, or change roles. * Do you have one, or even multiple sources of truth for employee identity metadata? * At least one source of identity is required to trigger Lifecycle Management actions when there are changes in the data source. This data source could be an HRIS system, identity provider, directory service, or an exported report. * Veza supports importing employee records from built-in [integrations](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/integrations.md), OAA integrations using the [Custom HRIS template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/hris-template.md), and [CSV upload](/4yItIzMvkpAvMVFAamTf/integrations/integrations/csv.md). * For example, you may have different sources of identity for full-time and employees and contractors. * What scenarios will be automated? * A range of applications can be sources of identity and targets for Lifecycle Management, with different actions supported for each integration. See [Actions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions.md) and [Integrations](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/integrations.md) for the current capabilities. #### Security considerations Implementing Lifecycle Management requires careful attention to access control, API key management, and credential handling to maintain security throughout your deployment. **Access control** **Limit administrative access**: Reduce standing administrator roles to those who need them. Best practice is no more than 5 administrators with standing access. **Use operator role for monitoring**: Users with Operator roles can view LCM policies without editing them. Use this role for monitoring and troubleshooting. **Temporary support access**: When working with Veza support on LCM issues, grant temporary administrator privileges using **Administration > Support User Access** rather than creating permanent accounts. **API key management** Monitor Veza API keys and disable unauthorized keys. API calls made with keys that have administrator privileges can modify LCM policies. **Key rotation best practices**: * Review API keys quarterly * Revoke keys that are no longer in use * Document the purpose of each active key * Use separate keys for different automation purposes **Integration credentials** **Credential lifecycle**: * Track credential expiration dates and renew before expiry * Avoid editing integration credentials except when renewing them * Test credential changes in a sandbox environment before applying to production **Critical system protection**: Identity source extractions are the most critical step in the LCM process. Handle integration configuration changes with care: * Schedule credential updates during maintenance windows * Verify extraction success immediately after credential changes * Have rollback procedures ready if extraction fails ### Define Segmentation Criteria (Business Roles) Begin by identifying and cataloging the different roles that can be assigned to employees and their digital identities within your organization. Users will be granted entitlements within target applications based on these business roles based on your Lifecycle Management [policies.md](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md). This list of business roles might be sourced from an organization chart, or a human resources information system (HRIS). These roles can be defined in terms of any discriminating attributes from a source of identity, such as: 1. Employee or contractor status 2. Roles and job positions 3. Business Units (BUs) 4. Locations 5. Define and list the different populations of employees with different levels of access in your organization (such as by roles, regions, and teams). 6. Organize the populations hierarchically, each inheriting the access granted to its parent population. For example, you might have a structure "All Employees" > "Sales Team" > "Sales Managers," with each inheriting the access granted to the parent. 7. Create a [Business Role](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md#business-roles) in Veza to model each segment. Example Business Roles: * Sales * Developers * Executive Employees * US Employees * China Employees ### Define Role Conditions Identify the attributes and conditions that will identify the segment each user belongs to. The possible attributes will depend on the employee metadata provided by your HRIS or other source of truth for identity. For example, you might assign certain Active Directory groups only to US employees, identified by a source Workday Worker's `work_location`. To define these conditions, you will need to understand what attributes are available within the source of truth, and how the values map to each employee segment. 1. Consider how employee records are structured in your source of identity, including all the built-in attributes belonging to an identity, and the possible values. 2. Check if any custom attributes can be used to define role conditions, and ensure these are enabled in the Veza Access Graph. 3. Document how employee populations correspond to the attribute values contained in the source of identity. **Examples: Source attributes for role conditions** The following standard attributes are available by all HRIS integrations that use an Open Authorization API template, along with any [custom properties](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/best-practices/oaa-custom-properties.md) enabled for the integration. You can typically import data from any HRIS system to Veza using this template, sourced from a generated report, API calls, or CSV data. #### OAA HRIS Built-In Attributes | Attribute | Description | | ----------------- | ------------------------------------------------------------------------------------------- | | Employee Number | Unique identifier for the employee. | | Company | The company or subsidiary the employee works for. | | First Name | Employee's first name. | | Last Name | Employee's last name. | | Preferred Name | Employee's preferred first name. | | Display Full Name | Full name for display; includes preferred first name if available. | | Canonical Name | Employee's canonical name. | | Username | Username as shown in the integration UI. | | Email | Employee's work email (unique). | | IDP ID | ID for connecting to the destination IDP provider. | | Personal Email | Employee's personal email. | | Home Location | Employee's home location. | | Work Location | Employee's work location. | | Cost Center | Cost center ID associated with the employee. | | Department | Department ID (Group ID) of the employee. | | Managers | List of employee IDs of the employee's managers. | | Groups | List of group IDs the employee is associated with. | | Employment Status | Employment status, e.g., `ACTIVE`, `PENDING`, or `INACTIVE`. | | Is Active | Indicates if the employee is active. | | Start Date | The date the employee started working. | | Termination Date | Employee's termination date, if applicable. | | Job Title | Employee's job title. | | Employment Types | Type of employment, e.g., `FULL_TIME`, `PART_TIME`, `INTERN`, `CONTRACTOR`, or `FREELANCE`. | | Primary Time Zone | Employee's primary time zone. | Using this standard identity metadata, a Lifecycle Management workflow runs specific actions for identities where some or all of the conditions are true: * **Employment Status** equals "Pending" * **Employment Types** equals "Full Time" * **Department** equals "Engineering" * **Work Location** equals "US" * **Cost Center** equals "R\&D" * **Start Date** on or after "2025-01-01" ### Define Profiles A Profile defines a set of entitlements for a specific application that can be assigned to users. For each target application, application owners will need to establish levels of birthright entitlements by defining **Profiles** mapped to groups, roles, or other entitlements that can be assigned to a user. 1. Review target applications to validate that the expected entitlements are configured, with the correct scopes and permissions for the Profiles they will be associated with. 2. Create Lifecycle Management [Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md#profiles) mapped to those entitlements. **Examples: Access Profiles** | Profile Name | Target | Relationship | | ----------------------- | ---------------- | -------------------------------------------------------- | | AD Executive Employees | Active Directory | Executive Employee - Manager US (Active Directory Group) | | AD Engineering Managers | Active Directory | Engineering - Manager US (Active Directory Group) | | Azure Helpdesk Role | Azure | Helpdesk Administrator (Azure AD Role) | | Google China Employees | Google Cloud | Google China Employees (Google Group) | When configuring the [Manage Relationships](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/manage-relationships.md) action, administrators can grant or revoke access by choosing a Business Role that inherits the desired Profile. ### Map Business Roles to Profiles Configure [Business Roles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md#business-roles) to inherit the corresponding access profiles, mapping entitlements to employee segments. 1. Create Business Roles for each segment. 2. For each Business Role, inherit a corresponding access profile. 3. Assign one or more Profiles to each Business Role as needed to fully define the birthright entitlements for each position. **Examples: Map Business Roles to Profiles** **Asia Employees** ```mermaid %%{init: { 'flowchart': { 'accessibilityTitle': 'Asia Employees Business Role hierarchy showing inheritance of Active Directory, Azure, Google, and Okta profiles' } } }%% flowchart TD ASIA["Business Role: Asia Employees"] AD["Profile: Active Directory:\nAsia Employees"] AZ["Profile: Azure:\nAsia Employees"] GG["Profile: Google:\nAsia Employees"] OK["Profile: Okta:\nAsia Employees"] ASIA --> AD ASIA --> AZ ASIA --> GG ASIA --> OK style ASIA fill:#f0f0ff,stroke:#333,stroke-width:2px style AD fill:#f8f8ff,stroke:#666 style AZ fill:#f8f8ff,stroke:#666 style GG fill:#f8f8ff,stroke:#666 style OK fill:#f8f8ff,stroke:#666 ``` **US Employees** ```mermaid %%{init: { 'flowchart': { 'accessibilityTitle': 'US Employees Business Role hierarchy showing inheritance of Active Directory, Azure, Google, and Okta profiles' } } }%% flowchart TD US["Business Role: US Employees"] AD["Profile: Active Directory:\nUS Employees"] AZ["Profile: Azure:\nUS Employees"] GG["Profile: Google:\nUS Employees"] OK["Profile: Okta:\nUS Employees"] US --> AD US --> AZ US --> GG US --> OK style US fill:#f0f0ff,stroke:#333,stroke-width:2px style AD fill:#f8f8ff,stroke:#666 style AZ fill:#f8f8ff,stroke:#666 style GG fill:#f8f8ff,stroke:#666 style OK fill:#f8f8ff,stroke:#666 ``` **Developers** ```mermaid %%{init: { 'flowchart': { 'accessibilityTitle': 'Developers Business Role hierarchy showing inheritance of Active Directory, Azure, and Okta developer profiles' } } }%% flowchart TD DEV["Business Role: Developers"] ADD["Profile: AD Developers"] AZD["Profile: Azure Developers"] OKD["Profile: Okta Developers"] DEV --> ADD DEV --> AZD DEV --> OKD style DEV fill:#f0f0ff,stroke:#333,stroke-width:2px style ADD fill:#f8f8ff,stroke:#666 style AZD fill:#f8f8ff,stroke:#666 style OKD fill:#f8f8ff,stroke:#666 ``` ### Define synced attributes Attributes from the source of identity can determine the attributes of users in target systems when creating or updating a target entity. For example, a provisioned Okta User's `country_code` might be set to a source Workday Worker's `work_location`. Additionally, the Okta User `manager` attribute could be continually synchronized to match the Worker’s `manager`. Target synced attributes can have fixed values (e.g., always `true`), can match a source attribute, or contain a combination of source values, transformed as needed to match the required format. Rules for synchronizing attributes are managed with [Transformers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers.md). 1. For each application, understand the supported attributes for provisioned users. 2. Assess the identity metadata from your source of truth to decide how source entity attributes will be used to set the values of target entity attributes. 3. Veza can synchronize attributes during provisioning and de-provisioning workflows, and whenever a change is detected in the source of identity. Decide which attributes should be kept in Continuous Sync, and which should only be created (and never modified after creating an entity). **Examples: Synced Attributes** **Sync Active Directory Accounts for Active Employees (Joiners/Movers)** When provisioning AD Users, create user attributes based on values in the source of identity. These attributes can also be kept up-to-date with the source of identity when there are changes, by enabling Continuous Sync. | Active Directory Attribute | Source Attributes | Transformer Value | | -------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------ | | account\_name | display\_full\_name | `{display_full_name}` | | distinguished\_name | first\_name, last\_name | `CN={first_name} {last_name},OU=Minnetonka,OU=US,OU=Evergreen Staff,DC=evergreentrucks,DC=local` | | user\_principal\_name | username | `{username}@evergreentrucks.com` | | email | username | `{username}@evergreentrucks.com` | | display\_name | display\_full\_name | `{display_full_name}` | | given\_name | first\_name | `{first_name}` | | sur\_name | last\_name | `{last_name}` | | country\_code | work\_location | `{work_location}` | | job\_title | job\_title | `{job_title}` | | primary\_group\_dn | - | `CN=Domain Users,CN=Users,DC=evergreentrucks,DC=local` | **Sync Active Directory Attributes for Withdrawn Employees (Leavers)** When disabling AD Users, update the DN and Primary Group DN to a group and OU reserved for terminated employees: | Active Directory Attribute | Source Attributes | Transformer Value | | -------------------------- | ----------------------- | ----------------------------------------------------------------------------------------------------- | | account\_name | display\_full\_name | `{display_full_name}` | | distinguished\_name | first\_name, last\_name | `CN={first_name} {last_name},OU=Evergreen Termination,OU=Evergreen Staff,DC=evergreentrucks,DC=local` | | primary\_group\_dn | - | `CN=Terminated Users,OU=Evergreen Groups,DC=evergreentrucks,DC=local` | * Moving leavers into a "Terminated Users" group (via the primary\_group\_dn attribute) effectively restricts access to systems that rely on Active Directory for authentication and authorization. * Updating the distinguished\_name to place leavers in a specific organizational unit (OU), like "Evergreen Termination," separates active users from inactive ones, and enables the application of policies, scripts, and queries that target inactive users without affecting active employees. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/getting-started/implementation.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.