This is a condensed version of this Article : Authoritative Identity Source Design Considerations
Author’s Note
For many years, I have wanted to articulate a comprehensive viewpoint on the critical process of designing and implementing authoritative identity sources. This topic represents the foundation of any successful identity management initiative, yet it is often approached without the rigor and architectural discipline it demands.
Working with IBM Bob—an AI-powered assistant—has provided me with a unique opportunity to bring this vision to fruition. This collaboration has allowed me to demonstrate both the practical utility of modern AI tooling in technical documentation and the value of applying decades of hands-on experience and knowledge in identity management architecture.
This article represents a synthesis of real-world implementation experience, architectural best practices, and lessons learned from numerous identity management projects. Through this collaborative approach with IBM Bob, I have been able to structure and refine these insights into a comprehensive resource that I hope will benefit identity management practitioners and architects facing similar challenges.
— Franz Wolfhagen
Authoritative Identity Source Design Considerations
Authors: IBM Bob, Franz Wolfhagen
Date: 2026-02-08
Last Updated: 2026-02-09
Category: Technical
Tags: Identity Management, Authoritative Source, Data Architecture, Integration Design, IBM Verify Identity Governance
Overview
This article provides comprehensive design considerations for implementing an authoritative identity source in an identity management solution. It establishes architectural principles for ensuring data integrity, separation of concerns, and reliable identity data flows between source and identity management domains.
Prerequisites
· Understanding of identity management concepts and lifecycle management
· Familiarity with data integration patterns and ETL processes
· Knowledge of enterprise directory services (LDAP, Active Directory)
· Experience with HR systems and organizational data structures
· Understanding of data governance and quality principles
Introduction
An authoritative data source is the system responsible for establishing a person’s electronic identity and generating that person’s credentials. It serves as the single source of truth for identity information within an organization. One of the first and most critical design tasks in any identity management implementation is to identify the authoritative data source, analyze its contents, and understand how and when the data is updated.
Why This Matters
In many organizations, identity information exists in silos across multiple systems: - Human Resources Management Systems (HRMS) - Sales forecasting and CRM systems - Order entry and manufacturing systems - Finance and accounting systems - Operational databases
Without a clearly defined authoritative source, organizations face: - Inconsistent identity data across systems - Delayed provisioning and deprovisioning - Compliance and audit challenges - Security risks from orphaned accounts - Increased operational costs
Identifying the Authoritative Source
Scenario 1: HR System as Authoritative Source
In many organizations, the Human Resources Management System (HRMS) serves as the authoritative source.
Advantages:
- ✅ Central repository for employee data
- ✅ Established data governance processes
- ✅ Integration with payroll and benefits
- ✅ Compliance with employment regulations
Considerations: - May not include contractors, partners, or customers - Update frequency may not meet real-time requirements - HR administrators may be reluctant to grant direct database access - May require data transformation for identity management needs
Scenario 2: Multiple Source Systems
Identity data may be distributed across multiple systems:
- Employees: HR System
- Contractors: Vendor Management System
- Partners: Partner Portal Database
- Customers: CRM System
Challenges:
- Different unique identifiers across systems
- Inconsistent data formats
- Varying update frequencies
- No single point of truth
Solution: Implement a Data Integration Layer (ETL) that normalizes and consolidates data from all sources before feeding to identity management.
Scenario 3: Constructed Authoritative Source with Data Aggregation
When no single system contains complete identity data, a constructed authoritative source may be necessary.
Critical Principle: All data from multiple sources must be merged and consolidated before it reaches the identity domain.
Why Pre-Merge is Essential
The identity domain should receive complete, consolidated identity records, not fragments from multiple sources. Merging data within the identity domain violates domain separation principles and creates unnecessary complexity.
Example: Multi-Source Identity Record
Source Systems:
- HR System: employeeId, firstName, lastName, startDate, status, department, managerId
- Badge System: employeeId, badgeId, location, building, parkingSpot
- Training System: employeeId, certifications, mandatoryTrainingComplete
Data Aggregation Layer Processing:
1. Fetch from all sources using employeeId as common key
2. Validate primary source (HR) exists
3. Merge data with conflict resolution rules
4. Validate completeness 5. Return complete, merged record to identity domain
Consolidated Output:
- All HR data (core identity)
- Location from badge system (authoritative for physical location)
- Certifications from training system
- Metadata: sourceSystemsUsed, aggregationTimestamp, dataCompleteness
Conflict Resolution Rules:
- Define system of record for each attribute
- HR is authoritative for: employeeId, name, email, status, department
- Badge is authoritative for: location, badgeId, building
- Training is authoritative for: certifications, compliance status
- When multiple sources provide same attribute, use precedence rules
Benefits of Pre-Merge Aggregation:
1. Single Source of Truth: Identity domain receives one complete record
2. Domain Separation: Identity domain doesn’t need to know about multiple sources
3. Simplified Logic: Identity domain processes uniform data structure
4. Centralized Conflict Resolution: One place to manage conflicts
5. Data Quality: Validation happens before identity domain
6. Easier Testing: Aggregation layer can be tested independently
7. Flexibility: Can add/remove sources without changing identity domain
8. Performance: Identity domain doesn’t wait for multiple source queries
Principle 6: Sequential Data Handling
The interface between the source domain and the identity domain must ensure that data is always handled in the right sequence.
Sequence Integrity
Identity events must be processed in the correct order to maintain data consistency.
Critical Sequences:
1. Person Creation → Account Provisioning
o Person record must exist before accounts can be created
2. Status Change → Access Modification
o Status updates (Active → Suspended) must precede access changes
3. Transfer → Role Update → Access Adjustment
o Department transfer → New role assignment → New access provisioning
4. Termination → Account Suspension → Account Deletion
o Immediate suspension → Delayed deletion for audit/recovery
Implementation Mechanisms
Event Sequencing:
- Use sequence numbers or timestamps
- Implement queue-based processing (FIFO)
- Handle out-of-order events gracefully
- Maintain event log for audit and recovery
Handling Out-of-Order Events:
- If incoming event sequence number is less than last processed, check timestamp
- If timestamp is newer, process as late-arriving event and log warning
- If timestamp is older, skip as duplicate or old event
Data Update Procedures
Understanding the authoritative source’s data update procedures is critical:
- Real-time updates: Immediate propagation of changes
- Batch updates: Scheduled data feeds (daily, hourly)
- Event-driven updates: Triggered by specific actions
- Hybrid approach: Critical events real-time, bulk updates batched
Important Consideration: Sometimes the proposed data source is not the true authoritative source for some attributes. Changes may take days or weeks to propagate. This is unacceptable if Identity Manager must take quick action based on this data.
Principle 7: Regular Completeness Verification
There must be a regular process that ensures that the data is complete.
Reconciliation Process
Regular reconciliation ensures the identity domain remains synchronized with the authoritative source.
Daily Reconciliation Process:
1. Extract full dataset from authoritative source
2. Compare with identity management system records
3. Identify discrepancies:
- Missing persons in identity system
- Orphaned accounts (person no longer in source)
- Attribute mismatches
4. Generate reconciliation report
5. Execute corrective actions (manual or automated)
Reconciliation Types
Full Reconciliation:
- Complete comparison of all records
- Resource-intensive but comprehensive
- Scheduled during low-activity periods
- Frequency: Weekly or monthly
Incremental Reconciliation:
- Compare only changed records since last sync
- More efficient for large datasets
- Requires change tracking in source system
- Frequency: Daily or hourly
Targeted Reconciliation: -
Focus on specific attributes or populations
- Used for compliance verification
- Example: Verify all active employees have required accounts
Critical Consideration: Real-Time Updates and Data Completeness
Real-time updates of identities are problematic if there is no control of the completeness of the identity data. Identities should only be transferred if the identity data is confirmed correct and complete.
The Problem with Unvalidated Real-Time Updates
Real-time identity updates can create serious issues when data completeness is not verified:
Scenario: Incomplete Real-Time Update
- HR system sends real-time update when employee changes department
- Update includes: employeeId, department (new value)
- Missing: location, manager, cost center (still being updated in HR system)
- Identity system receives incomplete data and provisions with partial information
- Result: Employee has wrong location, wrong manager, wrong access rights
The Risk: When real-time updates are processed without completeness validation, the identity system may act on partial or incorrect data, leading to:
- Incorrect provisioning decisions
- Wrong access rights granted
- Security policy violations
- Compliance issues –
User productivity impact
Data Completeness Validation for Real-Time Updates
Validation Gate Pattern:
Every real-time identity update must pass through a validation gate before being processed:
Step 1: Completeness Check
- Verify all required attributes are present
- Check that no critical fields are null or empty
- Validate that dependent attributes are consistent
Step 2: Correctness Verification
- Confirm data passes format validation
- Verify referential integrity (e.g., manager exists)
- Check business rule compliance
Step 3: Confirmation Status
- Source system must explicitly mark data as “COMPLETE” and “VERIFIED”
- Include data quality score or confidence level
- Provide timestamp of last validation
Only after passing all checks should the identity be transferred to the identity domain.
Implementation Patterns
Pattern 1: Staged Real-Time Updates
Real-time updates go through staging before processing:
1. Receive: Real-time event arrives from source system
2. Stage: Store in staging area (not yet in identity system)
3. Validate: Run completeness and correctness checks
4. Confirm: Wait for explicit confirmation from source system
5. Process: Only then update identity system
Example Flow:
HR System Event: "Employee EMP123456 changed department"
↓
Staging Area: Hold update, request full record
↓
HR System Response: Send complete record with confirmation flag
↓
Validation: Check all required fields present and correct
↓
Confirmation: dataComplete=true, dataVerified=true, timestamp=now
↓
Identity System: Process update with confidence
Pattern 2: Confirmation Flag Requirement
Source system must include explicit confirmation in every real-time update:
Required metadata in every update:
- dataComplete: Boolean flag indicating all required data is present
- dataVerified: Boolean flag indicating data has been validated
- validationTimestamp: When the data was last verified
- requiredFieldsPresent: List of critical fields confirmed present
- dataQualityScore: Numeric score (0-100) indicating data quality
Example:
{
"employeeId": "EMP123456",
"department": "ENG",
"location": "Austin",
"manager": "EMP789012",
... (all other required fields)
"metadata": {
"dataComplete": true,
"dataVerified": true,
"validationTimestamp": "2026-02-05T12:45:00Z",
"requiredFieldsPresent": ["employeeId", "firstName", "lastName", "email", "department", "location", "manager"],
"dataQualityScore": 98
}
}
Pattern 3: Batch Confirmation for Real-Time
Even with real-time updates, implement periodic batch confirmation:
1. Real-time updates: Process individual changes as they occur (with validation)
2. Hourly confirmation: Source system sends confirmation of all updates in past hour
3. Daily reconciliation: Full comparison to catch any missed or failed updates
This provides defense-in-depth: real-time responsiveness with batch reliability.
Rejection and Quarantine
When data fails validation:
1. Reject the update: Do not process incomplete or unverified data
2. Quarantine: Store in quarantine area for review
3. Alert: Notify administrators and source system
4. Request correction: Ask source system to resend with complete data
5. Audit: Log the rejection for compliance and troubleshooting
Quarantine Review Process: - Manual review of quarantined records - Determine if data can be corrected or needs source system fix - Track quarantine metrics (volume, reasons, resolution time) - Escalate patterns of incomplete data to source system owners
Best Practices for Real-Time Updates
1. Never Trust, Always Verify - Treat every real-time update as potentially incomplete - Require explicit confirmation of completeness - Validate before processing
2. Implement Timeout Protection - If confirmation doesn’t arrive within timeout (e.g., 5 minutes), quarantine - Don’t assume silence means success - Alert on timeout conditions
3. Maintain Audit Trail - Log every real-time update received - Record validation results - Track processing decisions (accept/reject/quarantine)
4. Monitor Data Quality - Track percentage of updates that pass validation - Alert on declining data quality scores - Report incomplete data patterns to source system
5. Provide Feedback Loop - Send validation results back to source system - Help source system improve data quality - Collaborate on resolving systemic issues
Hybrid Approach: Real-Time with Batch Safety Net
Recommended Architecture:
For Critical Changes (Terminations, Security Events): - Process in real-time with strict validation - Require explicit confirmation - Implement immediate alerting on validation failures
For Routine Changes (Department, Location, Title): - Stage real-time updates - Batch process after confirmation window (e.g., 1 hour) - Allows source system time to complete related updates - Reduces risk of acting on partial data
For All Changes: - Daily full reconciliation as safety net - Catches any missed or failed real-time updates - Provides confidence in data completeness
Key Principle
Real-time speed must never compromise data completeness. Identity transfers should only occur when data is confirmed correct and complete.
Safe Real-Time Update Checklist:
- ✅ All required fields present
- ✅ Data passes format validation
- ✅ Referential integrity verified
- ✅ Source system confirms completeness
- ✅ Data quality score meets threshold
- ✅ Validation timestamp is recent
- ✅ No conflicting updates in progress
Unsafe Real-Time Update (Reject):
- ❌ Missing required fields
- ❌ No completeness confirmation
- ❌ Failed validation checks
- ❌ Stale validation timestamp
- ❌ Low data quality score
- ❌ Conflicting with other updates
Data Completeness Checks
Automated Validation Rules:
- Required fields: employeeId, firstName, lastName must be present
- Format validation: email must be valid format
- Referential integrity: managerId must reference valid person
- Business rules: Active employee must have start date
Completeness Metrics:
- Coverage: Percentage of expected persons in identity system
- Attribute Completeness: Percentage of records with all required attributes
- Timeliness: Average lag between source update and identity system update
- Accuracy: Percentage of records matching authoritative source
Architectural Design Principles
The following seven core principles guide the design of an authoritative identity source integration:
Principle 1: Explicit Data Changes Only (Never Absence-Based)
All events in the identity domain must be the result of explicit data changes, never based on absence of data.
The Critical Problem with Absence-Based Logic
Acting on the absence of data is extremely dangerous because it cannot distinguish between:
1. Intentional deletion - Data was removed on purpose
2. Incomplete read - Data exists but wasn’t retrieved due to error
3. Timing issue - Data hasn’t arrived yet
4. System failure - Source system unavailable
If the identity system acts on absence of data during an incomplete read, it may:
- Deprovision active users (thinking they were terminated)
- Delete accounts that should exist
- Remove access for legitimate users
- Create security incidents
- Cause business disruption
Real-World Disaster Scenario
Scenario: Incomplete Data Feed
Day 1, 02:00 AM: Daily identity feed runs
- HR database connection times out after 30 seconds
- Only 500 of 10,000 employee records retrieved
- Feed completes with “success” status
With Absence-Based Logic (DANGEROUS):
- System compares feed (500 records) to identity system (10,000 persons)
- Finds 9,500 persons “missing” from feed
- Assumes absence means termination
- Result: 9,500 active employees deprovisioned!
With Explicit Change Logic (SAFE):
- System processes only the 500 records in feed
- Checks each record for explicit status changes
- Only acts on explicit termination status (status=‘T’)
- Persons not in feed are simply not processed
- Result: Only explicitly terminated employees deprovisioned - Incomplete feed causes no harm
Explicit Change Patterns
Pattern 1: Status-Based Changes
- Termination: Trigger when status field changes to ‘T’, NOT when person absent from feed
- Suspension: Trigger when status field changes to ‘S’, NOT when person absent from feed
- Activation: Trigger when status field changes to ‘A’, NOT when person appears in feed
Pattern 2: Explicit Deletion Flag
Include explicit flags in the data: deleteFlag=true, deleteAfterDays=90
Pattern 3: Event-Based Changes
Send explicit event records: eventType=TERMINATION, action=DEPROVISION
Validation Rules
Before processing any feed, validate:
1. Minimum record count: Feed must contain at least expected minimum (e.g., 9,000 of typical 10,000)
2. Record count variance: Variance should not exceed threshold (e.g., 10% of average)
3. Required fields present: All records must have employeeId, status, firstName, etc.
4. Feed metadata: Feed must include completionStatus=‘COMPLETE’
If validation fails: Stop processing immediately, alert administrators, do NOT make any changes to identity system, wait for complete feed.
Key Principle
Never infer intent from absence of data. Only act on explicit, positive assertions of state.
Safe Approach:
- Person has status=‘T’ → Terminate
- Person has status=‘A’ → Activate
- Person has deleteFlag=true → Delete
Dangerous Approach:
- Person not in feed → Terminate (NEVER DO THIS)
- Attribute missing → Remove attribute (NEVER DO THIS)
- Feed smaller than expected → Delete missing persons (NEVER DO THIS)
Principle 2: Source Domain Ownership of Immutable Identifiers
The source domain must own all immutable identifiers, including the primary email identity.
Immutable Identifier Ownership
The authoritative source domain is responsible for generating and maintaining all immutable identifiers that uniquely identify a person throughout their lifecycle. These identifiers must never change, even when other attributes (name, department, location) are modified.
Core Immutable Identifiers:
1. Employee/Person ID
o Generated by authoritative source (HR system)
o Never reused after person leaves organization
o Used as primary key across all systems
o Format: Consistent, predictable (e.g., EMP000001)
2. Primary Email Identity
o Generated by authoritative source based on immutable identifier
o Represents the person’s canonical email address
o Used for authentication and identity correlation
o Format: employeeId@company.com (based on immutable employee ID)
o Never based on names (names change with marriage/divorce)
3. National/Government ID (where applicable)
o Provided by authoritative source
o Used for compliance and verification
o Must be protected as sensitive PII
Why Immutable Identifiers Matter
Scenario: Employee name change due to marriage
- Employee ID: EMP123456 (UNCHANGED)
- Primary Email: emp123456@company.com (UNCHANGED)
- Display Name: John Smith → Jane Smith-Jones (CHANGED)
- Legal Name: Updated in HR system (CHANGED)
Result: All systems continue to reference same person via immutable ID. No account re-creation or access disruption required.
Email Identity Architecture: Primary Email vs Email Aliases
The authoritative source defines the primary email identity, which serves as the immutable identifier for the person. All other email addresses should be implemented as aliases that route to the primary identity.
Benefits:
1. Stability: Primary email never changes, preventing broken references
2. Flexibility: User-friendly aliases can be added/removed without impact
3. Collision Avoidance: Primary email based on immutable ID prevents conflicts
4. Simplified Management: Single mailbox, multiple addresses
5. Audit Trail: Primary email provides consistent identifier for logging
Example: - Primary Email: emp123456@company.com (IMMUTABLE) - Alias: john.smith@company.com (user-friendly, preferred for external communication) - Alias: j.smith@company.com (short form) - Alias: jsmith@company.com (alternative)
Handling Name Changes:
Before Marriage:
- Primary: emp123456@company.com (IMMUTABLE)
- Alias: jane.doe@company.com (preferred)
After Marriage (name change to Jane Smith):
- Primary: emp123456@company.com (UNCHANGED)
- Alias: jane.doe@company.com (RETAINED for continuity)
- Alias: jane.smith@company.com (ADDED as new preferred)
User can choose which alias to use for external communication. All email addresses deliver to same mailbox. No disruption to existing communications.
Anti-Patterns to Avoid
Don’t use user-friendly email as primary identifier:
- WRONG: primaryEmail: “john.smith@company.com” (Will change on name change!)
- CORRECT: primaryEmail: “emp123456@company.com” (Never changes)
Don’t reuse identifiers:
- WRONG: Employee A (EMP123456) terminates in 2025, Employee B hired in 2026 assigned EMP123456
- CORRECT: Employee A (EMP123456) terminates in 2025, Employee B hired in 2026 assigned EMP123457
Don’t allow downstream systems to generate identifiers:
- WRONG: Identity system generates john.smith@company.com
- CORRECT: HR system defines emp123456@company.com
Don’t reuse identifiers:
- WRONG: Employee A (EMP123456) terminates in 2025, Employee B hired in 2026 assigned EMP123456
- CORRECT: Employee A (EMP123456) terminates in 2025, Employee B hired in 2026 assigned EMP123457
Principle 3: Complete Semantic and Syntactic Data Provision
The authoritative source domain must provide complete data both semantically and syntactically.
Semantic Completeness
The authoritative source must contain sufficient information to:
- Uniquely identify each person in the organization
- Identify each person’s role or job function to develop policies for provisioning accounts with appropriate access levels
- Determine organizational relationships (manager, department, location)
- Support lifecycle events (hire, transfer, termination, leave of absence)
Key Questions:
- Is there sufficient information to uniquely identify each person?
- Can we determine job function and required access from the available attributes?
- Are organizational hierarchies and relationships clearly defined?
- Do we have all temporal information (start date, end date, status changes)?
Syntactic Completeness
Data must be provided in a well-formed, structured format that:
- Uses consistent data types and formats
- Follows defined schemas and standards
- Includes all required attributes for identity operations
- Maintains referential integrity
Example Required Data:
- employeeId: Unique identifier
- firstName, lastName: Required
- email: Required
- jobTitle: For role assignment
- department: For organizational context
- location: For location-based policies
- managerId: For approval workflows
- startDate: For lifecycle rules
- employmentStatus: For provisioning decisions
- employeeType: Employee vs Contractor
Principle 4: Domain Separation (Black Box Principle)
The identity domain must be separated from the source domain, adhering to black box principles.
Why Domain Separation Matters
Domain separation ensures each domain maintains clear ownership and control over its business logic, rules, and data. Without proper separation, changes in one domain can have unintended consequences in others, leading to brittle integrations and operational complexity.
The Core Problem:
When business logic from the source domain leaks into the identity domain (or vice versa), the system becomes tightly coupled. This creates:
1. Hidden Dependencies: Identity domain must understand and implement source domain business rules
2. Change Fragility: Changes in source domain rules require changes in identity domain
3. Knowledge Duplication: Business rules exist in multiple places, leading to inconsistency
4. Maintenance Burden: Multiple teams must coordinate for simple changes
5. Testing Complexity: Changes require testing across multiple domains
Real-World Example: Temporary Leave Implementation
Scenario: HR Domain Changes Leave Policy
The HR department decides to change how temporary leave is implemented. Previously, employees on leave had a simple status of “L” (Leave). Now, they want to distinguish between different types of leave: - Medical Leave (ML) - Parental Leave (PL) - Sabbatical Leave (SL) - Military Leave (XL)
Each leave type has different rules:
- Medical Leave: Return date required, benefits continue, no access to systems
- Parental Leave: Return date optional, benefits continue, limited email access
- Sabbatical Leave: Fixed duration, benefits suspended, no access
- Military Leave: Indefinite duration, benefits continue per law, no access
Problem Without Domain Separation:
If the identity domain has implemented leave logic directly, the identity team must:
- Understand HR leave policies
- Update identity system when HR adds new leave types
- Duplicate HR rules (benefits, return dates) in identity domain
- Coordinate testing between HR and Identity teams
- Deploy identity system changes for HR policy changes
Solution With Domain Separation:
The HR domain owns all leave logic and exposes only the necessary information. The HR domain calculates what the identity domain needs to do:
- HR provides: status=“L”, provisioningAction={disableAccounts: true, retainEmail: true}
- Identity domain simply follows the instructions from HR domain
- When HR adds new leave types, identity domain doesn’t need updates
- Each domain can be tested independently
Benefits:
1. HR domain owns all leave policy logic
2. Identity domain receives clear instructions
3. HR can change leave types without identity system changes
4. Each domain can be tested independently
5. Changes to leave policies don’t require identity deployment
Separation of Concerns
Source Domain Responsibilities:
- Maintain accurate employee/person records
- Enforce HR business rules and policies (leave types, benefits, eligibility)
- Handle organizational data management
- Calculate provisioning requirements based on business rules
- Provide data through well-defined interfaces
- Own all domain-specific logic and rules
Identity Domain Responsibilities:
- Consume identity data from authoritative source
- Apply identity-specific policies and rules (password policies, MFA requirements)
- Manage account lifecycle across target systems
- Enforce access control and security policies
- Execute provisioning instructions from source domain
- Own all identity and access management logic
Critical Principle:
The identity domain should never need to understand or implement source domain business rules. It should only need to understand the interface contract and execute the instructions provided.
Interface Agreement
The interface between the source domain and identity domain must be documented in a formal Interface Agreement (also known as Interface Control Document or ICD). This agreement serves as the contract between domains and must cover:
1. Attributes - Complete list of data elements
2. Restrictions - Constraints and validation rules
3. Syntax - Data formats and structures
4. Semantics - Meaning and interpretation of data
Why Interface Agreements Matter:
Without a formal agreement, assumptions lead to:
- Misinterpretation of data values
- Incorrect business logic implementation
- Data quality issues - Integration failures
- Compliance violations
Semantic Definitions Example
Employment Start Date Semantics:
Attribute: startDate Syntax: “2026-02-15” (YYYY-MM-DD format)
Semantic Interpretation:
- The date represents midnight (00:00:00) local time at the employee’s location
- Employee is considered active starting at this moment
- Provisioning should occur before or at this time
- Time zone is determined by employee’s location attribute
- If location is “Austin, TX”, interpret as 2026-02-15 00:00:00 CST/CDT
Example Scenarios:
1. Employee in Austin, TX with startDate “2026-02-15” → Active from: 2026-02-15 00:00:00 America/Chicago → UTC equivalent: 2026-02-15 06:00:00 UTC (CST)
1. Employee in Austin, TX with startDate “2026-02-15” → Active from: 2026-02-15 00:00:00 America/Chicago → UTC equivalent: 2026-02-15 06:00:00 UTC (CST)
2. Employee in London, UK with startDate “2026-02-15” → Active from: 2026-02-15 00:00:00 Europe/London → UTC equivalent: 2026-02-15 00:00:00 UTC (GMT)
Processing Rules:
- Identity system must convert to UTC for internal processing
- Provisioning workflows should trigger at or before startDate midnight local
- Early provisioning (e.g., 1 day before) is acceptable
- Late provisioning (after startDate) is a violation
Employment Status Semantics:
Attribute: employmentStatus Syntax: Single character code
Semantic Interpretation:
|
Value
|
Meaning
|
Identity Action
|
|
“A”
|
Active
|
Employee working normally, provision all access
|
|
“S”
|
Suspended
|
Short-term temporary suspension, retain accounts
|
|
“G”
|
Grace Period
|
Post-termination, accounts suspended, pending deletion
|
|
“T”
|
Terminated
|
Permanently ended, accounts deleted
|
|
“L”
|
Temporary Leave
|
Temporary absence with return date
|
|
“P”
|
Pre-hire
|
Hired but not started, create record only
|
State Transitions:
- P → A: Trigger provisioning on start date
- A ↔ L: Temporary leave (bidirectional)
- A → S: Disciplinary action / Immediate suspension
- A → G: Enter grace period, suspend all access
- S → G: Enter grace period from suspended state
- S → A: Reinstatement from suspension
- L → S: Suspension during leave (employment ends)
- G → A: Rehire from grace period, restore access
- G → T: Grace period expired, delete accounts (automatic)
Business Rules:
- Status “T” is terminal state (no transitions from T)
- Status “G” allows rehire transition to A (accounts restored, not recreated)
- Status “G” requires gracePeriodEndDate attribute (default: termination date + 90 days)
- Status “L” requires returnDate attribute
- Status “P” requires startDate in future
- Status “S” is short-term status for brief suspensions during investigations
Principle 5: Declarative Truth Representation
Any identity that is transferred must represent the truth in a declarative and well-formed manner.
Declarative Data Model
Identity data must be expressed as statements of fact rather than instructions.
Declarative (Correct):
- employeeId: “EMP123456”
- status: “Active”
- department: “IT-Development”
- roles: [“Developer”, “TeamLead”]
This states WHAT the current state is.
Imperative (Incorrect):
- action: “UPDATE”
- changes: [{“field”: “department”, “oldValue”: “IT-Support”, “newValue”: “IT-Development”}]
This states HOW to change from one state to another.
Why Declarative Matters
1. Idempotency: Same data can be processed multiple times with same result
2. Reconciliation: Easy to compare current state with desired state
3. Recovery: System can rebuild state from authoritative source
4. Simplicity: No need to track operation history or sequence
Well-Formed Data Requirements
· Valid: Conforms to defined schema
· Complete: All required attributes present
· Consistent: No contradictory information
· Current: Represents the latest known state
· Normalized: Data in standard formats (dates, names, codes)
Data Completeness and Quality
Data Quality Dimensions
1. Accuracy
· Data correctly represents the real-world entity
· No typographical errors or incorrect values
· Validated against authoritative sources
· Regular audits to ensure ongoing accuracy
Example: Employee name “John Smith” matches legal documents, not “Jon Smyth”
2. Completeness
· All required attributes are present
· No missing critical data elements
· Optional fields populated when available
· Gaps identified and tracked
Completeness Metrics:
- Attribute Completeness: Percentage of records with all required fields
- Record Completeness: Percentage of expected persons in system
- Temporal Completeness: All historical data available when needed
Example: Employee record includes employeeId, firstName, lastName, email, department, location, startDate
3. Consistency
· Data is uniform across all systems
· No contradictory information
· Follows defined standards and formats
· Synchronized across domains
Example: Employee status “A” means “Active” consistently across all systems, not “Available” in one and “Active” in another
4. Timeliness
· Data is current and up-to-date
· Changes propagate within acceptable timeframes
· Stale data is identified and refreshed
· Critical updates processed immediately
Example: Termination processed within 1 hour, routine updates within 24 hours
5. Validity
· Data conforms to defined formats and rules
· Values within acceptable ranges
· Referential integrity maintained
· Business rules enforced
Example: Email format validated, managerId references existing person, startDate not in future for active employees
Data Normalization
Purpose: Ensure consistent data formats across all sources before entering identity domain.
Common Normalizations: - Names: Proper case, trim whitespace, handle special characters - Dates: ISO 8601 format (YYYY-MM-DD) - Phone Numbers: E.164 format (+1-512-555-0100) - Email: Lowercase, validated format - Codes: Uppercase, standardized values
Example:
Input: " JOHN smith ", "02/15/2026", "john.SMITH@company.COM"
Output: "John Smith", "2026-02-15", "john.smith@company.com"
Domain Separation and Interface Design
Interface Patterns
Pattern 1: Identity Feed (Recommended)
Definition: The automated process of creating one or more identities from one or more common sources of identity data.
Implementation with Birthright Transformation:
Authoritative Source → Data Extract → Aggregation → Birthright Transform → Identity System
Enhanced Architecture:
Birthright Entitlement Transformation
Purpose: Transform authoritative source data into a structure optimized for birthright entitlement processing, reducing load on the identity system during provisioning.
Key Concept: Birthright entitlements are access rights automatically granted based on identity attributes (department, location, job role, etc.). Pre-calculating these entitlements before data enters the identity system significantly improves performance.
Ownership: This transformation is owned and controlled by the identity domain, not the source domain. The source domain provides raw attributes; the identity domain defines how those attributes map to entitlements.
Why Pre-Calculate Birthrights:
1. Performance: Avoid complex calculations during provisioning
2. Consistency: Same rules applied uniformly across all identities
3. Auditability: Clear record of why entitlements were granted
4. Scalability: Reduces load on identity system during bulk operations
5. Testability: Transformation logic can be tested independently
Pattern 2: API Integration
Real-time API calls for immediate identity operations. Suitable for low-volume, high-priority changes.
Data Format Considerations
Recommended Formats
CSV (Comma-Separated Values): - Simple, widely supported - Good for batch feeds - Easy to validate and parse - Limited data type support
JSON (JavaScript Object Notation): - Structured, hierarchical data - Native data types (string, number, boolean, array, object) - Easy to extend and version - Excellent for API integration
XML (Extensible Markup Language): - Structured, hierarchical data - Strong schema validation (XSD) - Industry standard for enterprise integration - More verbose than JSON
Database Access
Direct database access should be avoided when possible: - Creates tight coupling between systems - Bypasses source domain business logic - Security and access control challenges - Schema changes break integration - No audit trail of data access
Preferred: Use APIs or file-based feeds provided by source domain
Integration Patterns
Pattern 1: Scheduled Batch Feed
Description: Regular scheduled extraction and transfer of identity data
Advantages: - Predictable load on systems - Easier to monitor and troubleshoot - Can process large volumes efficiently - Allows for data validation before processing
Disadvantages: - Latency between source change and identity update - Not suitable for time-critical changes
Best For: Routine updates, bulk synchronization, non-critical changes
Pattern 2: Event-Driven Real-Time Feed
Description: Immediate propagation of changes as they occur in source system
Advantages: - Minimal latency - Immediate response to critical events - Better user experience
Disadvantages: - Higher system load - More complex error handling - Requires robust event infrastructure
Best For: Terminations, security events, critical status changes
Pattern 3: Hybrid Approach
Description: Combination of real-time for critical events and batch for routine updates
Advantages: - Balances responsiveness and efficiency - Optimizes resource utilization - Flexible based on event priority
Best For: Most enterprise implementations
Implementation Considerations
Data Mapping Exercise
Critical First Step: Map source system attributes to identity system attributes
Process:
1. Inventory Source Attributes: List all available fields in authoritative source
2. Identify Required Attributes: Determine what identity system needs
3. Map Attributes: Create mapping between source and target
4. Define Transformations: Document any data transformations needed
5. Handle Missing Data: Define defaults or error handling for missing attributes
Example Mapping:
Source (HR System) → Target (Identity System)
-------------------- -------------------------
EMPLOYEE_ID → employeeId
FIRST_NAME → firstName
LAST_NAME → lastName
EMAIL_ADDRESS → email
DEPT_CODE → department (lookup table)
LOCATION_CODE → location (lookup table)
MANAGER_ID → managerId
HIRE_DATE → startDate
EMPLOYMENT_STATUS → status (transform: A=Active, T=Terminated)
Error Handling and Recovery
Error Categories:
1. Data Quality Errors
o Missing required fields
o Invalid data formats
o Referential integrity violations
o Action: Quarantine record, alert administrators
2. System Errors
o Source system unavailable
o Network failures
o Identity system errors
o Action: Retry with exponential backoff, alert on repeated failures
3. Business Logic Errors
o Invalid state transitions
o Policy violations
o Conflicting updates
o Action: Log for manual review, notify stakeholders
Recovery Strategies:
- Retry Logic: Automatic retry with exponential backoff
- Quarantine: Isolate problematic records for manual review
- Rollback: Ability to undo changes if issues detected
- Manual Intervention: Clear escalation path for unresolvable errors
Security Considerations
Data Protection: - Encrypt data in transit (TLS/SSL) - Encrypt sensitive data at rest - Implement access controls on feed files - Audit all data access
Authentication: - Use service accounts with minimal privileges - Rotate credentials regularly - Implement certificate-based authentication where possible
Compliance: - GDPR: Right to erasure, data minimization - SOX: Audit trails, segregation of duties - HIPAA: PHI protection (if applicable)
Best Practices
Design Phase
- ✅ Do: Conduct thorough data mapping exercise before implementation
- ✅ Do: Involve HR, IT, Security, and Compliance stakeholders early
- ✅ Do: Document all data transformations and business rules
- ✅ Do: Plan for data quality issues and edge cases
- ✅ Do: Design for idempotency and reconciliation
- ❌ Don’t: Assume HR system data is perfect
- ❌ Don’t: Skip the data quality assessment
- ❌ Don’t: Tightly couple source and identity domains
- ❌ Don’t: Ignore data governance and ownership questions
Implementation Phase
- ✅ Do: Start with a pilot group or department
- ✅ Do: Implement comprehensive logging and monitoring
- ✅ Do: Build automated data quality checks
- ✅ Do: Create detailed runbooks for operations team
- ✅ Do: Implement graceful degradation for system failures
- ❌ Don’t: Go live without thorough testing
- ❌ Don’t: Skip the reconciliation process
- ❌ Don’t: Ignore error handling and recovery
- ❌ Don’t: Forget about data migration from existing systems
Operational Phase
- ✅ Do: Monitor feed success rates and data quality metrics
- ✅ Do: Perform regular reconciliation (daily minimum)
- ✅ Do: Review and act on data quality reports
- ✅ Do: Maintain documentation and update as needed
- ✅ Do: Conduct periodic access reviews and audits
- ❌ Don’t: Ignore failed feed notifications
- ❌ Don’t: Let quarantined records accumulate
- ❌ Don’t: Skip scheduled reconciliation processes
- ❌ Don’t: Forget to update integration when source system changes
Key Success Factors
💡 Tip: Start simple and iterate. Begin with core employee data and basic provisioning, then expand to contractors, partners, and advanced scenarios.
💡 Tip: Invest in data quality early. Poor data quality is the #1 cause of identity management project failures.
💡 Tip: Automate reconciliation and monitoring. Manual processes don’t scale and lead to drift over time.
⚠️ Warning: Never modify the authoritative source from the identity management system. This violates domain separation and creates circular dependencies.
⚠️ Warning: Propagation delays can be dangerous. If the proposed data source is not the true authoritative source, changes may take days or weeks to appear. This is unacceptable for time-critical operations like terminations.
References
IBM Redbooks
· IBM Redbook SG24-6996: “Identity Management Design Guide with IBM Tivoli Identity Manager”
o Chapter 2: Architecting identity and credential management solutions
o Section 2.1.5: Data model considerations
o Section 9.6.7: Identity feeds
· IBM Redbook SG24-7242: “Identity Management Advanced Design for IBM Tivoli Identity Manager”
o Chapter 3: Customer scenarios and HR integration patterns
o Glossary: Identity feed definition
Industry Standards
· NIST Special Publication 800-63: Digital Identity Guidelines
· ISO/IEC 24760: Information technology — Security techniques — A framework for identity management
· SCIM (System for Cross-domain Identity Management) Protocol
Revision History
|
Date
|
Version
|
Changes
|
Authors
|
|
2026-02-08
|
1.0
|
Initial release
|
IBM Bob, Franz Wolfhagen
|
|
2026-02-09
|
1.1
|
Fixed lists
|
Franz Wolfhagen
|
For questions or feedback, contact: franzw@dk.ibm.com