Ellipse Gradient for Header

One Identity Integration Guide

Connect One Identity Manager, Active Roles, Safeguard, and Starling services with enterprise systems through product-specific REST APIs, SOAP services, files, and scheduled workflows.

One Identity integration options at a glance

One Identity is a portfolio, so integration mechanisms vary across One Identity Manager, Active Roles, Safeguard, and Starling services. REST APIs are the primary standards-based option for current integrations, while selected products or legacy scenarios may expose SOAP or other web-service interfaces. One Identity Manager also supports synchronization projects, provisioning, import/export processing, and batch-oriented workflows. Product-specific notifications or callbacks may be available, but universal webhook coverage is not confirmed. Martini can consume the applicable API, process JSON or XML, run scheduled reconciliation workflows, transform identity objects, handle controlled batches, and expose a REST API for downstream systems.

Integration pointSupported by One Identity?Common use casesHow Martini supports it
REST APIsYesOne Identity Manager, Active Roles, and Safeguard provide REST-oriented interfaces for identity, directory, privileged-access, and administrative operations. Exact endpoints and object coverage vary by product and release.Martini can consume the applicable REST API, authenticate using environment-managed configuration, transform JSON payloads, apply business rules, and orchestrate writes to downstream systems.
SOAP APIsLimitedSelected One Identity products or legacy integration scenarios may expose SOAP or web-service interfaces. Availability must be confirmed for the deployed product and release.Martini can consume a documented WSDL or SOAP endpoint, map XML request and response structures, and handle product-specific faults and retries.
Webhooks / outbound callbacksLimitedSome products or cloud services may provide event, notification, or callback features, but universal webhook coverage for object changes is not confirmed.Where a documented callback exists, Martini can expose an API endpoint to receive it and start a workflow. Otherwise, Martini can use scheduled incremental polling and reconciliation.
Bulk / async / batch APIsLimitedOne Identity Manager supports synchronization, provisioning, and import-oriented batch processing. API-level bulk behavior differs across Active Roles and Safeguard.Martini can implement controlled batching, pagination, checkpoints, bounded concurrency, and retry handling even where a native bulk endpoint is unavailable.
File / import-export processingLimitedOne Identity Manager supports synchronization projects and import/export-oriented integration patterns, especially for initial loads or systems that cannot use an API.Martini can process supported structured files, validate and transform rows, invoke downstream workflows, and report rejected or incomplete records.
Database / analytics accessLimitedOne Identity Manager commonly uses Microsoft SQL Server, but direct database integration is deployment-specific and is not the preferred operational contract.Martini can connect to permitted databases where required for controlled reporting or analytics, while operational provisioning should prefer supported APIs or synchronization mechanisms.
AuthenticationYesAuthentication varies by product and can involve configured credentials, directory security, roles, sessions, or tokens. Safeguard API workflows use token-based authentication in documented examples.Martini stores credentials, tokens, client secrets, and endpoint settings in environment-specific secrets and applies least-privilege access to workflows.

How One Identity exposes data and business events

One Identity REST APIs

REST is the primary standards-based integration mechanism across One Identity Manager, Active Roles, and Safeguard, although available resources, authentication, and object coverage depend on the product and release.

Martini implementation pattern

Martini implementation pattern: Martini invokes the documented product-specific REST endpoint from a workflow, stores endpoint and authentication configuration as environment secrets, maps JSON responses into a canonical model, applies business rules, and writes validated results to downstream systems.

Implementation sequence

Identify the One Identity product, release, and REST resources
Configure the endpoint and least-privilege credentials
Retrieve or submit the required object payload
Validate identifiers, statuses, and required attributes
Map the response to the target application model
Apply provisioning, approval, or reconciliation rules, then write the result

One Identity SOAP services

SOAP or web-service interfaces may be available for selected products or legacy administration and synchronization scenarios. SOAP is not a universal One Identity capability and must be confirmed against the deployed product documentation.

Martini implementation pattern

Martini implementation pattern: Martini consumes a documented WSDL, constructs XML requests, handles SOAP faults, maps XML responses, and keeps the SOAP integration behind a reusable workflow or API boundary.

Implementation sequence

Confirm the product-specific WSDL and supported operations
Configure endpoint authentication and transport security
Build the XML request from validated source data
Call the SOAP operation and inspect the response or fault
Transform the XML response into the canonical model
Retry transient faults and route permanent failures for review

Product-specific notifications and callbacks

Some One Identity products or Starling services may provide notifications, events, or callbacks, but comprehensive webhook coverage for all identity and access changes was not confirmed.

Martini implementation pattern

Martini implementation pattern: Where a documented callback is available, Martini exposes a controlled API endpoint, validates the notification, retrieves the current One Identity resource when necessary, and processes the event idempotently. When callbacks are unavailable, a scheduler-triggered workflow performs incremental polling.

Implementation sequence

Confirm the product-specific event or callback contract
Expose and secure the Martini receiving API when callbacks are supported
Validate the notification and correlation data
Retrieve the current object or change details if required
Apply mapping and business rules before updating targets
Persist a checkpoint or idempotency key and record the processing result

Scheduled reconciliation

Scheduled synchronization, provisioning, and reconciliation are central One Identity Manager patterns and provide a fallback when product-specific event delivery is unavailable or incomplete.

Martini implementation pattern

Martini implementation pattern: A scheduler starts a workflow that queries modified objects, follows pagination, compares source and target identifiers, applies create, update, disable, and delete rules, and persists progress for restartable processing.

Implementation sequence

Start the workflow on a controlled schedule
Load the last successful checkpoint and bounded query window
Retrieve changed Persons, Employees, accounts, groups, or requests
Follow pagination and normalize the returned objects
Compare stable identifiers and apply idempotent target changes
Store the checkpoint and produce reconciliation and exception results

Import and export files

One Identity Manager supports import, export, synchronization, and batch-oriented data exchange for scenarios such as initial loads or systems that cannot use an API.

Martini implementation pattern

Martini implementation pattern: Martini receives or reads an approved structured file, validates headers and required values, maps rows to One Identity Manager objects or downstream models, reports row-level errors, and tracks the batch outcome.

Implementation sequence

Receive or locate the approved import or export file
Validate the file format, headers, and required fields
Parse and normalize each Person, Employee, account, or role row
Apply duplicate, status, and entitlement rules
Submit valid rows through the supported integration mechanism
Publish rejected rows and store the batch completion status

Common One Identity integration patterns

Pattern 1: Provision identity lifecycle changes to directories

When to use this pattern

Use this pattern for joiner, mover, and leaver processing where One Identity Manager provides governed Person, Employee, User Account, and role data for directory provisioning. It supports controlled account creation, attribute updates, group membership, and deprovisioning.

Integration direction
One Identity Manager
Martini
Active Directory
Example Mapping
One Identity FieldCanonical FieldTarget Field
Person.UID_PersonpersonIdemployeeId or externalId
Employee.PersonnelNumberemployeeNumberemployeeNumber
Employee.FirstNamegivenNamegivenName
Employee.LastNamefamilyNamesurname
Martini implementation pattern

Martini retrieves approved changes through the One Identity Manager API, synchronization mechanism, or supported export. The workflow validates lifecycle status, maps the identity to the directory model, applies create, update, group, and disable rules, and uses stable identifiers for idempotent writes. Transient failures are retried and unresolved records are routed to an exception result.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • scheduled synchronization
  • error handling

Pattern 2: Load authoritative workforce data into One Identity Manager

When to use this pattern

Use this pattern when Workday or another HR source is authoritative for worker, employment, and organization data. One Identity Manager can then continue governed provisioning to directories and applications.

Integration direction
Workday
Martini
One Identity Manager
Example Mapping
One Identity FieldCanonical FieldTarget Field
Worker.Employee_IDemployeeNumberEmployee.PersonnelNumber
Worker.NamepersonNamePerson.DisplayName
Worker.Employment_StatusemploymentStatusEmployee.IsInActive
Worker.OrganizationorganizationIdEmployee.UID_Org
Martini implementation pattern

Martini retrieves changed workforce data, normalizes dates and status values, validates manager and organization references, and maps records to Person and Employee objects. The workflow distinguishes creates from updates, rejects incomplete source data before writing, and uses checkpoints and reconciliation reporting for large populations.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • validation
  • business rules
  • checkpointing

Pattern 3: Orchestrate Safeguard access requests with ServiceNow

When to use this pattern

Use this pattern when ServiceNow requests and approvals must initiate or track privileged access in One Identity Safeguard. It provides correlation between the business request, Safeguard operation, and resulting audit status.

Integration direction
ServiceNow
Martini
One Identity Safeguard
Example Mapping
One Identity FieldCanonical FieldTarget Field
ServiceNow.request.numberrequestIdSafeguard request correlation
ServiceNow.requested_forrequesterIdSafeguard Directory User
ServiceNow.approval.statusapprovalStatusAccess Request approval state
ServiceNow.configuration_itemassetReferenceSafeguard Asset
Martini implementation pattern

Martini receives or retrieves approved ServiceNow request data, verifies entitlement and approval conditions, calls the documented Safeguard REST operation, and writes the Safeguard identifier and status back to ServiceNow. Duplicate submissions are prevented with correlation keys, while transient API failures use bounded retries.

Martini capabilities used
  • workflows
  • API consumption
  • API exposure
  • data mapping
  • business rules
  • error handling

Pattern 4: Reconcile One Identity objects with SaaS accounts

When to use this pattern

Use this pattern for periodic synchronization between Active Roles or One Identity Manager and applications such as Salesforce or Jira when universal event delivery is unavailable or incomplete.

Integration direction
One Identity Manager
Martini
Salesforce
Example Mapping
One Identity FieldCanonical FieldTarget Field
User Account.AccountNameloginusername
User Account.UID_PersonpersonIdexternalId
Application Role.RoleNameaccessProfileprofile or permission set
User Account.IsDisabledaccountStatusisActive
Martini implementation pattern

A scheduled Martini workflow retrieves changed accounts and role assignments, pages through source collections, maps identity and authorization data to the SaaS API, and compares external identifiers before creating or updating users. Disablement and role-removal rules are explicit, and failures are recorded for retry or manual review.

Martini capabilities used
  • scheduler triggers
  • API consumption
  • pagination
  • data mapping
  • idempotent processing
  • monitoring

Applications commonly integrated with One Identity

One Identity commonly participates in identity lifecycle, directory administration, privileged access, and audit architectures. The exact integration contract depends on the selected One Identity product, deployment model, release, and available API or synchronization mechanism.

Application Scenario Direction Martini Pattern
Active Directory Provision and deprovision directory accounts, groups, and organizational memberships as part of identity lifecycle processing. One Identity Manager → Martini → Active Directory Martini consumes One Identity Manager or Active Roles data, maps stable identity and membership identifiers, applies joiner, mover, and leaver rules, and invokes the supported directory endpoint or exchange mechanism. Reconciliation checkpoints and idempotent updates prevent duplicate account actions.
Microsoft Entra ID Synchronize cloud identities, groups, and lifecycle status with governed identity processes. One Identity Manager → Martini → Microsoft Entra ID A Martini workflow retrieves approved Person, Employee, User Account, or group changes, transforms them into the Microsoft Entra ID model, validates required attributes, and records target identifiers for repeatable updates and deprovisioning.
Workday Provide authoritative worker, employment, and organizational data for identity lifecycle processing. Workday → Martini → One Identity Manager Martini retrieves available worker and organization data from Workday, maps it to One Identity Manager Person and Employee objects, applies status and organizational business rules, and submits validated changes through the configured One Identity API or import mechanism.
SAP Provision or reconcile SAP users, roles, and account attributes within broader enterprise identity governance. One Identity Manager → Martini → SAP Martini orchestrates approved One Identity Manager changes, transforms account and role attributes to the SAP integration contract, separates creates from updates and disables, and routes rejected or transient operations for retry or review.
ServiceNow Link access requests, approvals, tickets, and privileged-access activity with One Identity processes. ServiceNow → Martini → One Identity Safeguard Martini receives or retrieves ServiceNow request data, validates approval and entitlement rules, calls the documented Safeguard REST API where supported, and writes request status, identifiers, and audit references back to ServiceNow.
Salesforce Apply identity lifecycle and access-management policies to Salesforce users and profiles. One Identity Manager → Martini → Salesforce Martini maps One Identity Manager or Active Roles user status and attributes to Salesforce users, applies profile and deprovisioning rules, invokes the target API, and reconciles Salesforce identifiers and statuses on a schedule.
Jira Synchronize user access or connect identity-related requests and approvals with project workflows. One Identity Manager → Martini → Jira A Martini workflow maps governed identity or request data to Jira users or workflow records, applies approval and lifecycle rules, handles API pagination, and records target identifiers for idempotent reconciliation.
Splunk Send identity, privileged-access, audit, or administrative events to security analytics workflows. One Identity → Martini → Splunk Martini retrieves supported audit or status data, normalizes product-specific fields, removes unnecessary sensitive values, adds correlation metadata, and forwards approved events through the available Splunk ingestion mechanism.

How to build a One Identity integration in Martini

Objective

Identify the exact One Identity product, release, deployment model, endpoint, authentication method, and required permissions before building the workflow.

Instructions in Martini

  • Select One Identity Manager, Active Roles, Safeguard, or the applicable Starling service.
  • Confirm the product-specific API, SOAP, callback, synchronization, or file interface.
  • Store credentials, tokens, client secrets, and endpoint settings in environment-managed secrets.
  • Use a dedicated least-privilege integration identity.

Objective

Select event-driven processing only where the product documents a suitable notification or callback; otherwise use scheduled incremental synchronization.

Instructions in Martini

  • Confirm whether the selected product and event type support an outbound notification or callback.
  • Expose a secured Martini API when a documented callback is available.
  • Use a scheduler trigger for polling, reconciliation, or file-based batches.
  • Define an initial full-load strategy separately from incremental processing.

Objective

Read or receive the relevant One Identity objects while controlling pagination, query windows, batch size, and checkpoint state.

Instructions in Martini

  • Retrieve Person, Employee, User Account, role, request, asset, or other product-specific objects.
  • Follow continuation links or page controls where provided.
  • Filter by modified time, status, or stable identifiers when supported.
  • Persist a checkpoint for restartable synchronization.

Objective

Coordinate source retrieval, validation, transformation, target writes, correlation, and exception handling in a maintainable Martini workflow.

Instructions in Martini

  • Separate retrieval, mapping, business rules, target writes, and result reporting into clear workflow stages.
  • Use correlation identifiers across One Identity and target systems.
  • Apply bounded concurrency to avoid overloading an API Server or appliance.
  • Keep product-specific logic reusable behind workflow or API boundaries.

Objective

Transform product-specific One Identity objects into a canonical model and target-specific payloads while rejecting unsafe or incomplete changes.

Instructions in Martini

  • Map actual objects such as Person, Employee, User Account, Application Role, IT Shop Request, or Access Request.
  • Validate required identifiers, lifecycle states, approvals, and references before writes.
  • Normalize dates, statuses, names, and role values.
  • Avoid logging credentials, tokens, privileged secrets, or unnecessary personal data.

Objective

Enforce lifecycle, entitlement, approval, duplicate, and deprovisioning rules before modifying downstream systems.

Instructions in Martini

  • Distinguish creates, updates, disables, and already-completed operations.
  • Check approval state before provisioning access or privileged requests.
  • Use stable external identifiers to make writes idempotent.
  • Route missing references, conflicting roles, and policy violations to exceptions.

Common One Identity data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
PersonRepresents an individual in One Identity Manager identity lifecycle processes.Workday, Active Directory, Microsoft Entra ID, SalesforceMartini retrieves or receives Person data, validates stable identifiers and required attributes, maps it to a canonical identity model, and synchronizes approved changes.
EmployeeCarries employment and lifecycle information used for joiner, mover, and leaver processing.Workday, One Identity Manager, Active Directory, Microsoft Entra IDMartini transforms employment status, organization, manager, and dates into target-specific fields and applies provisioning or deprovisioning rules.
User AccountRepresents an account associated with an identity and its lifecycle state.Active Directory, Microsoft Entra ID, Salesforce, SAPMartini uses stable One Identity keys and external identifiers to create, update, disable, and reconcile accounts idempotently.
Application RoleDefines application-oriented access or authorization assignments in One Identity Manager.SAP, Salesforce, Jira, Microsoft Entra IDMartini maps role assignments to target permission models, checks approval or entitlement rules, and routes unsupported or conflicting assignments for exception handling.
IT Shop RequestRepresents a request for access, entitlement, or other governed identity activity.ServiceNow, One Identity Manager, SafeguardMartini correlates request identifiers, validates status and approvals, orchestrates downstream actions, and writes results or failure details back to the request system.
Access RequestSafeguard object used to represent privileged-access request activity.ServiceNow, Safeguard, security monitoring platformsMartini consumes or submits supported request operations through the Safeguard API, preserves correlation identifiers, and synchronizes status and audit metadata.

Authentication and security considerations

Product-specific authentication

One Identity authentication depends on the selected product, deployment, release, and endpoint. Configured credentials, directory security, roles, sessions, or tokens may apply. Safeguard API workflows use token-based authentication in documented examples, but the exact method must be confirmed for the deployed release.

Least privilege and secret handling

Use dedicated integration identities with only the permissions required for selected objects and operations. Store credentials, tokens, client secrets, and endpoint configuration in Martini environment-managed secrets rather than workflow definitions.

Protect sensitive data

  • Use TLS-protected endpoints and access-controlled workflow logs.
  • Do not log passwords, tokens, privileged-account secrets, or unnecessary personal data.
  • Separate read-only reconciliation from write and provisioning workflows where practical.
  • Preserve vendor request and correlation identifiers for controlled auditing.

Operational considerations for One Identity integrations

Product and version differences

One Identity is a portfolio rather than one uniform API. Confirm the product, release, deployment model, licensed features, endpoint paths, object coverage, and authentication method before implementation.

Pagination, limits, and concurrency

Collections of users, groups, accounts, assets, requests, or audit records may be paginated. Follow continuation links, use bounded page sizes, apply server-side filters, and control concurrency. Rate limits and appliance capacity vary by product and deployment.

Idempotency and reconciliation

Use stable object keys, Person or Employee identifiers, directory identifiers, Safeguard identifiers, and external application IDs. Make updates safe to repeat, distinguish already-disabled objects from failures, persist checkpoints, and run periodic reconciliation.

Retries and schema changes

Use bounded exponential backoff for transient failures and route permanent errors to an exception process. Validate response schemas and required fields because API paths and object properties can differ between products and releases.

Testing and recovery

Test full loads, incremental changes, duplicate messages, rejected attributes, approval failures, deprovisioning, API timeouts, and restart behavior in a non-production environment. Include reconciliation reports, dead-letter or exception handling, and manual recovery paths.

Why use Martini instead of scripts or point-to-point integrations?

Adapt to a product portfolio

One Identity integrations vary across Manager, Active Roles, Safeguard, and Starling services. Martini provides a consistent workflow and API-led implementation model while preserving product-specific endpoint, object, and authentication behavior.

Reduce point-to-point complexity

Instead of embedding identity rules in separate scripts, Martini centralizes retrieval, transformation, validation, approvals, target writes, checkpoints, and exception handling in maintainable workflows.

Support multiple integration styles

Martini can consume REST or SOAP services, receive documented callbacks, run scheduled reconciliation, process supported files, and expose a controlled API for downstream systems without requiring a dedicated One Identity connector.

Operate reliably

  • Apply reusable mappings and business rules across products and targets.
  • Use environment-specific secrets and endpoint configuration.
  • Implement pagination, idempotency, retries, checkpoints, and reconciliation.
  • Monitor workflow results and preserve useful correlation data without exposing sensitive values.

Frequently asked questions

How can One Identity be integrated with enterprise systems?

One Identity integrations depend on the selected product. One Identity Manager, Active Roles, and Safeguard provide REST-oriented APIs, while selected products or legacy scenarios may provide SOAP or web-service interfaces. One Identity Manager also supports synchronization, provisioning, import/export, and batch-oriented processing. Product-specific callbacks may be available, but scheduled incremental synchronization is often required where event coverage is incomplete.

Can Martini integrate with One Identity?

Yes. Martini can integrate with One Identity by consuming the applicable One Identity REST API, using SOAP where the deployed product supports it, processing supported One Identity Manager files or synchronization outputs, and receiving documented product-specific callbacks. The implementation must target a specific One Identity product and release.

Do I need a connector to integrate One Identity with Martini?

No. A dedicated One Identity connector is not required. Martini can use the relevant product's native REST APIs, SOAP services, files, authentication methods, synchronization mechanisms, or documented callbacks, with workflows handling orchestration, mapping, validation, and error recovery.

Is there any extra Lonti cost to integrate One Identity with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate One Identity. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from One Identity, cloud infrastructure, or other third-party systems depending on licensing, usage, and deployment model.

Which One Identity integration method should be used?

REST APIs are the primary choice for newer integrations where the selected product exposes the required resources. One Identity Manager synchronization or import/export mechanisms are relevant for lifecycle and batch processing. SOAP is a secondary, product-specific option, and direct database access is generally not recommended for operational provisioning.

Are One Identity webhooks, events, or callbacks available?

Not universally. Some One Identity products or Starling services may provide product-specific notifications or callbacks, but comprehensive webhook coverage for all identity, account, group, and access events was not confirmed. Martini can receive a documented callback or use scheduled incremental polling and reconciliation when an event mechanism is unavailable.

How does Martini synchronize One Identity data?

Martini can run real-time workflows where a supported notification exists, or scheduled workflows that retrieve changed objects using timestamps, version fields, status filters, or product-specific audit information. The workflow maps objects such as Persons, Employees, User Accounts, Groups, Assets, or Access Requests, persists checkpoints, and performs idempotent target updates.

How does Martini handle mapping, errors, retries, and duplicates in One Identity integrations?

Martini maps product-specific payloads into canonical and target models, validates required fields, and applies lifecycle or entitlement rules before writing. Workflows can use stable One Identity keys and external identifiers for idempotency, bounded retries for transient failures, pagination and checkpoints for long-running jobs, and exception or reconciliation reporting for permanent failures.