> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/identity.md). # Identity foundation The decisions that settle what a person is in your estate — which feeds may assert a person exists, what value links their accounts, what identifier the enterprise uses, and which populations the desi ## What this is, and when you need it Part 2 is about the layer everything else stands on: **what a person is in your estate, and what links the accounts that belong to them**. None of it is a configuration question. All of it is decided before a connector is built, and all of it is expensive to revisit — a correlation key changed after a hundred thousand accounts have been linked is a re-matching exercise across every managed system, not a settings change. You need this part when you are drafting the design rather than reviewing it: when you are working out which system is allowed to say a person exists, what value the joiner feed will be matched on, whether the organization needs an identifier it does not yet have, and how a contractor who becomes an employee in March and a contractor again in November is going to be represented. Read it in order once. It is written as a sequence because the answers depend on each other. The single most common failure in this part is to leave the correlation key implicit — to assume that because the feed "obviously" carries an employee number, the question is answered. It is not answered until someone has proved the value is present on every population, unique across the whole estate, and immutable for the life of a person's relationship with the organization. OpenIAM will not check any of those three for you. ## The decisions in this part | Decision | Where it is made | What it turns on | | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Which systems may assert that a person exists, has changed, or has left | [Choosing your authoritative sources](/solution-architecture/identity/authoritative-sources.md) | Whether one HR system covers the whole workforce, and who owns the populations it does not | | Which OpenIAM field a feed is matched on, and what happens when two records collide | [Identity correlation: choosing a matching key](/solution-architecture/identity/correlation-key.md) | Whether a single trusted, immutable value reaches OpenIAM on every record from every source | | What that value actually is — a payroll number, a minted enterprise identifier, or a composite | [Choosing the enterprise unique identifier](/solution-architecture/identity/unique-identifier.md) | How many HR systems you have, whether payroll numbers are reused, and whether contractors have one at all | | How a person's several accounts, privileged accounts and service accounts hang together | [One person, many accounts](/solution-architecture/identity/one-person-many-accounts.md) | How many directories and forests a person exists in, and whether administrative work is done from a second account | | Which populations the lifecycle has to handle, and what a transition between them means | [Designing for every population](/solution-architecture/identity/populations.md) | Contractors, seasonal returners, conversions, partners, customers and non-human identities | The order in that table is the order to decide them in. Authority comes first because it determines what data you will actually have; the correlation key comes next because everything downstream depends on it; the enterprise identifier is the answer to "we do not have a good key", which is a conclusion you can only reach after the first two. ## What Part 2 assumes, and what it hands to other parts This part does not describe OpenIAM's object model — *The OpenIAM object model* in the Administration Guide does that, and does it better than a restatement would. What Part 2 does is apply that model to an estate that already exists: several directories, more than one HR system, a population of people who are not employees and never will be. Two boundaries are worth naming now. **Authentication is Part 3, and it depends on this part rather than the other way round.** A person must be known in OpenIAM and known in the target application before single sign-on can work at all; a federation design built on an identity model that cannot survive a transfer will fail at the first transfer. **Governance is Part 4**, and it inherits whatever this part decided: a certification campaign can only attest to accounts that were correlated to a person, and an orphan account is precisely an account this part failed to attach to anybody. Where a second governance platform is in play, Part 5 adds constraints that belong here: two platforms can only maintain one enterprise view of a person if they agree on what identifies that person, and the identifier is the thing that has to be settled first. ## Related * [Choosing your authoritative sources](/solution-architecture/identity/authoritative-sources.md) — the feed that is allowed to say a person exists, and what to do when two feeds disagree. * [Identity correlation: choosing a matching key](/solution-architecture/identity/correlation-key.md) — the most consequential decision in this part. * *The OpenIAM object model* in the Administration Guide — the model these decisions are applied to. * Part 5, *Coexistence and migration* — the constraints a second governance platform adds to every decision here. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/identity.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.