1. Introduction

Identity Governance and Administration (IGA) projects require a balanced approach, integrating both business objectives and technical specifications. A well-defined set of requirements is crucial to guide the implementation team and ensure project success. This document serves as a framework to capture essential information for developing new connectors within the OpenIAM platform.

2. Supported Functionality

Begin by identifying the operations the connector should support. The table below outlines potential operations. Indicate which are applicable to your system:

3. Authoritative Source & Data Mapping

Most systems integrated through connectors will not be authoritative sources for user identity data. However, when a system does act as an authoritative source (e.g., an HR system), it is crucial to define the attributes relevant for IAM that it manages and map them to OpenIAM attributes.

If the connector is integrating a system that will be an authoritative source, provide:

• A list of attributes managed by the system.
• The corresponding OpenIAM attribute mapping.

Example Mapping for an Authoritative Source:

Even if a system is not an authoritative source, an initial data load from the application into OpenIAM is required when importing existing users and entitlements. This ensures that OpenIAM accurately reflects the current access landscape.

Additionally, many systems require ongoing reconciliation (e.g., a nightly synchronization process) to keep OpenIAM in sync with the application. For both the initial load and ongoing reconciliation, data must be mapped to OpenIAM attributes.

For Initial Data Load and Reconciliation:

• Identify user attributes that must be imported.
• Map these attributes to OpenIAM.
• Define whether the process will be a one-time import or require periodic synchronization.

If API integration is required, provide API endpoints and relevant documentation links.

4. Importing Entitlements

Importing entitlements (e.g., groups, roles, permissions) from an application into OpenIAM is essential for several reasons:

• Populate the service catalog – Allows users to request specific access via OpenIAM’s request and approval workflows.
• See what access a person currently has – Provides visibility into a user’s entitlements directly within OpenIAM.
• Define business roles and business rules – Helps in automating role assignments and implementing policies based on predefined conditions.
• Support access certification processes – Enables compliance activities by providing a structured view of access rights during certification campaigns.

To ensure a successful entitlement import process, provide the following details:

• Integration Nature: Specify whether the integration utilizes an API, SDK, Database, or Directory.
• API/SDK: Detail the API calls or reference the API documentation. List attributes involved in the calls.
• Database: Identify the tables or views containing the data. Provide a list of fields and their meanings.
• Directory: Describe how integration will operate, whether through user profile attributes or group memberships.

5. Importing Users and Their Entitlements

Importing users and their entitlements is a critical step in any IAM integration, as it ensures that OpenIAM has an accurate and complete representation of user access across systems. This process serves multiple key purposes:

• Baseline for Identity Governance – Provides a foundational dataset that enables OpenIAM to manage and govern identities effectively.
• Enhances Visibility & Reporting – Allows organizations to see which users have access to what, supporting compliance, auditing, and security initiatives.
• Supports Access Reviews & Certification – Enables managers and compliance officers to review access periodically and make informed decisions.
• Enables Ongoing Synchronization – Ensures that user information and entitlements remain accurate over time through periodic reconciliation processes.

To capture current user access levels:

• Integration Nature: Specify whether the integration utilizes an API, SDK, Database, or Directory.
• API/SDK: Detail the API calls or reference the API documentation. List attributes involved in the calls.
• Database: Identify the tables or views containing the data. Provide a list of fields and their meanings.
• Directory: Specify the directory segment (filter) in focus. Describe integration details, such as user profile attributes or group memberships.

6. User Provisioning Operations

User provisioning operations enable OpenIAM to manage user lifecycle events within an integrated system. These operations define how users are created, updated, disabled, and deleted in external applications. Ensuring that provisioning aligns with business and security policies is essential for automation, compliance, and efficient access control.

There are several key types of provisioning operations that an OpenIAM connector may need to support:

1. User Creation (Joiner Process)

• Automatically or manually create user accounts in the target application.
• Assign initial roles, groups, or permissions.
• Ensure the user ID and other attributes conform to predefined naming conventions.
• Define uniqueness rules to prevent duplicate accounts.

2. User Updates (Mover Process)

• Modify user attributes (e.g., job title, department, email).
• Update roles and entitlements based on role changes or policy updates.
• Reflect organizational changes (e.g., transfers between departments).

3. Enable/Disable User

• Temporarily disable a user account (e.g., for extended leave or policy violations).
• Reactivate accounts when users return.
• Define whether entitlements should be retained, revoked, or reassigned.

4. User Deletion (Leaver Process)

• Determine whether user accounts should be deleted or retained (e.g., for audit purposes).
• Implement a soft-delete (e.g., change account status) or a hard-delete (remove the account permanently).
• Define how to handle orphaned accounts and linked entitlements.

To support user provisioning operations, provide the following details:

• Nature of the Integration: API, SDK, Database, or Directory.
• API/SDK: Detail the API calls or reference the API documentation. List attributes involved in the calls.
• Database: Identify the tables or views containing the data. Provide a list of fields and their meanings.
• Directory: Specify how provisioning is handled via directory attributes or group memberships.

Unique ID Generation:

• Define rules for generating unique user IDs and other attributes that need to be generated.
• Ensure compatibility with system constraints (e.g., character limits in Active Directory).
• Define uniqueness rules (e.g., collision handling if a username is already taken).

7. Enable/Disable User

This operation allows the activation or deactivation of user accounts. It is often used for temporary suspensions or reactivations.

8. Password Management

For password-related operations:

• Integration Nature: Specify whether the integration utilizes an API, SDK, Database, or Directory.
• API/SDK: Detail the API calls or reference the API documentation. List attributes involved in the calls.

9. Search/Find Operations

The Search/Find operation is a critical component of the OpenIAM connector framework, supporting various use cases, including user lookups, synchronization, and access provisioning. This operation enables OpenIAM to:

• Locate specific user records to support update, delete, and password change operations.
• Perform incremental synchronization by retrieving only the records that have changed since the last sync.
• Execute full synchronization when an initial load or complete refresh is required.
• Ensure data consistency between OpenIAM and external applications.

Flexibility in Search Parameters

To support different use cases, the search operation must be flexible and allow for multiple query parameters, including:

1. User Lookup by Specific Identifier

• Retrieve a single user based on a unique attribute (e.g., userId, email, employeeNumber).
• This is useful for targeted updates, deletions, or troubleshooting.

2. Incremental Synchronization

• Retrieve all records that have changed since the last successful synchronization (e.g., based on lastUpdatedTimestamp).
• This is necessary for maintaining real-time updates without reloading all records, improving efficiency.

3. Full Synchronization

• Retrieve all users from the source system, regardless of recent changes.
• This is used for initial data loads or periodic full syncs to ensure OpenIAM maintains an accurate and complete dataset.

To support search operations, provide the following:

• Nature of the Integration: API, SDK, Database, or Directory.
  • API/SDK: Detail the API calls or reference the API documentation. List attributes involved in the calls.
  • Database: Identify the tables or views containing the data. Provide a list of fields and their meanings.
  • Directory: Specify search parameters such as filtering by attributes or searching within specific organizational units (OUs).
• Defining Incremental Sync Criteria:
  • Identify the field used to track changes (e.g., lastModified, lastLogin, statusChange).
  • Specify how the connector should handle deletions in incremental sync (e.g., is a soft-delete flag used?).
• Search Performance Considerations:
  • Define any limitations on search queries (e.g., max number of records returned in a single call).
  • Describe any available filtering mechanisms (e.g., searching by department, role, or status).

10. Additional Considerations

• Security: Authentication and authorization mechanisms for API access.
• Error Handling: Define how errors are reported and handled in the integration.
• Performance Expectations: Document any throughput or response time expectations for API calls. Also include any rate limiting controls that may be in place that can potentially slow down API calls.
• Logging & Monitoring: Specify logging and monitoring requirements to track provisioning activities.