> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/oaa/best-practices/cross-service-connections.md). # Cross Service IdP Connections Mapping OAA objects to external and federated identities In Veza, the Identity Provider (IdP) serves as the representation of the source of an identity (human or otherwise). That identity can have access to many applications, clouds and other data sources. By connecting OAA entities to source IdP identities, Veza can show all the access for that identity. This can also enable powerful correlation queries such as finding deactivated Okta Users with active application accounts. Veza makes these connections based on the identity information provided in the OAA payload. Veza Supports Mapping for the following Identity Providers: * Active Directory * Azure AD * Custom IdP * Google Workspace * Okta * OneLogin For all Identity Providers, the `IdP Unique ID` and `email` attributes are used to match the source identity to an OAA principal. Some entity types have additional properties usable for identity mapping: * Active Directory * Account Name * Distinguished Name * Azure AD * Principal Name * On Premises SAM Account Name * Okta * User Login Comparison ignores case, and is otherwise an exact match on the whole value. Veza does not strip domains, ignore punctuation, or compare email aliases when resolving identities from a payload. For Google Workspace, the compared values are the primary email address only. For the full per-provider attribute list, the attributes Veza does not compare, such as employee IDs, and guidance on identities that fail to resolve, see [Automatic Identity Matching](/4yItIzMvkpAvMVFAamTf/integrations/configuration/automatic-identity-matching.md). To correlate on an attribute outside that list, configure a [custom identity mapping](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md) on the identity provider integration. ### Application Template The Application Template's Local User entity represents a user within the application. That Local User can map to an Identity Provider (IdP) by setting the identity value(s) in the Local Users `identities` array. Veza will use these identities to create an association between the IdP Identity and the Local User. The Local User's `email` property is a display attribute and is not compared. Populate `identities` even when the same address is already set in `email`. Veza uses the first value in `identities` that resolves and creates one connection per Local User, so additional values act as alternatives rather than as additional connections. A Local User in the [Custom Principal template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/custom-principal-template.md), used by several built-in connectors, connects to every identity that resolves. Setting external IdP Group `identities` is also supported on Local Groups. This should be used when there are no Local User records in the application that correlate to the external user identities. Veza will create a connection between the IdP Group and the Local Group, indicating that all IdP users from that group will have the access granted to the Local Group. Unknown identities set on users will result in a warning that the identity can not be found. The OAA Local User will still be successfully created. > **Note on Identity Mapping from the IdP**: You can confirm these values by finding the corresponding entity in Veza search or the data catalog and checking the identities *Idp Unique Id* and other fields in the details view. Identities that cannot be resolved are returned as warnings when the application payload is pushed. For applications that use Okta for SSO, you can also enrich local users with last login timestamps from Okta activity data. Set `okta_app_id` on the application object to enable this enrichment — Veza uses the same `identities` values to match local users to their Okta profiles. See [Okta SSO last login enrichment](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/rest-api/okta-sso-last-login.md). ### Identity Provider (IdP) Template OAA Identity Provider Users can be connected to other IdPs by using the `source_identity` property on the IdP users. For details see [Source Identity Assignments](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/custom-identity-provider-template.md#source-identity-assignments) ### Human Resources Information System (HRIS) Template Veza correlates HRIS Employee records to IdP identities using one value per employee, taking the first of `idp_id`, `email`, and `employee_number` that is set. Set the optional `idp_id` when the value that identifies the employee in the IdP is not their email address. Veza then compares that single value against the IdP attributes listed above, so an `employee_number` correlates only when it is also the IdP login, principal name, or email address. For details, see [HRIS template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/hris-template.md#identity-mappings). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/oaa/best-practices/cross-service-connections.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.