---
id: SOV09
pillar: sovereignty
title: SOV 9. How do you federate identity without importing a dependency you did not intend?
description: Identity is the control plane for everything else. A sovereign workload authenticated through a non-sovereign identity provider has a dependency worth naming.
status: draft
services: [stackit-idp, service-accounts]
tiers: [1, 2]
sidebar:
  order: 18
  label: Identity sovereignty
source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/sov-09-identity-sovereignty/"
source_file: "docs/architecture/pillars/sovereignty/sov-09-identity-sovereignty.mdx"
---

Identity sits above everything else in this pillar. Whoever operates the identity provider decides
who can authenticate, and therefore who reaches the data that the rest of these questions
carefully placed and encrypted.

Federation is the right architecture and the standard practice: one directory, one lifecycle, one
place to disable an account. The question is not whether to federate but what the resulting chain
looks like, and whether anybody has looked at it.

## Best practices

- [`SOV 9.1`](/architecture/pillars/sovereignty/sov-09-identity-sovereignty/#sov-91-establish-who-operates-your-identity-control-plane) Establish who operates your identity control plane
- [`SOV 9.2`](/architecture/pillars/sovereignty/sov-09-identity-sovereignty/#sov-92-keep-identity-inside-the-boundary-where-the-tier-requires-it) Keep identity inside the boundary where the tier requires it
- [`SOV 9.3`](/architecture/pillars/sovereignty/sov-09-identity-sovereignty/#sov-93-design-the-recovery-path-which-depends-on-identity) Design the recovery path, which depends on identity
- [`SOV 9.4`](/architecture/pillars/sovereignty/sov-09-identity-sovereignty/#sov-94-include-workload-identity-not-only-human-identity) Include workload identity, not only human identity

---

## SOV 9.1 Establish who operates your identity control plane

**Risk if not established:** High

Trace the authentication chain from the person to the data and note who operates each link. For
most organizations the chain runs from a corporate directory through a federation to the
platform's identity service, and each link is a party in the sense [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/) means.

The consequential link is usually the upstream directory rather than the platform. If that
directory is operated by a provider outside the intended boundary, then the authority deciding who
may authenticate sits there, regardless of where the workload runs.

This is not automatically a problem. Federating to an existing corporate directory is normal and
avoids a second identity estate, which has its own risks. It is a dependency to name rather than a
defect to remove.

Include what the upstream can do beyond authentication. An identity provider that can create
accounts, alter group membership or reset credentials can grant access as well as verify it, and
the chain is as strong as the weakest authority in it.

**On STACKIT.** <LinkChip href="https://docs.stackit.cloud/platform/access-and-identity/stackit-idp/">STACKIT
IdP</LinkChip> is the platform
identity service, and it supports federation to an upstream provider through <LinkChip href="https://docs.stackit.cloud/platform/access-and-identity/stackit-idp/how-tos/generic-oidc-1_0-federation-guide/">generic
OIDC</LinkChip>
and <LinkChip href="https://docs.stackit.cloud/platform/access-and-identity/stackit-idp/how-tos/saml-2_0-federation-guide/">SAML
2.0</LinkChip>,
with
<LinkChip href="https://docs.stackit.cloud/platform/access-and-identity/stackit-idp/how-tos/scim-endpoint/">SCIM</LinkChip>
for provisioning.

Those two protocols are the important part for this question. Because the federation is expressed
through open standards rather than a fixed list of providers, the upstream can be any conforming
identity provider, including one you operate yourself or one within your intended boundary. The
documented guides for <LinkChip href="https://docs.stackit.cloud/platform/access-and-identity/stackit-idp/how-tos/microsoft-entra-id-federation-guide/">Microsoft Entra
ID</LinkChip>
and <LinkChip href="https://docs.stackit.cloud/platform/access-and-identity/stackit-idp/how-tos/google-workspace-federation-guide/">Google
Workspace</LinkChip>
are conveniences for the common cases rather than the boundary of what is possible.

That distinction is what makes this a genuine architectural choice. Federating to a widely used
corporate directory is a legitimate decision with a dependency attached; the standards-based path
means the decision is available to be made differently where the tier requires it.

**Tradeoffs.** **Operational Excellence.** A separate identity estate for sovereign workloads
means two directories, two lifecycles and two places to disable an account, which is a real risk
of its own.

**Verify.** Draw your authentication chain from person to data. Who operates each link, and under
which jurisdiction?

---

## SOV 9.2 Keep identity inside the boundary where the tier requires it

**Risk if not established:** Medium

Where the tier makes the upstream dependency unacceptable, the alternatives are ordered by how
much they cost rather than by how sovereign they are.

**Federate to a provider inside the boundary**, which keeps the federation architecture and
changes the upstream. This is the cheapest option where such a directory exists or can exist.

**Use the platform's identity service directly** for the sovereign workload, which removes the
upstream entirely and creates a second identity estate to operate.

**Operate your own identity provider** inside the boundary, which gives full control and full
operational burden including its availability, its patching and its own disaster recovery.

Scope the decision to the workload rather than the organization. A Tier 1 workload can have its
own identity arrangement while everything else federates normally, which is [`SOV 1.3`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/#sov-13-classify-per-data-set-because-a-workload-rarely-sits-at-one-tier) applied to
identity, and it confines the cost to where the requirement is.

**On STACKIT.** All three are available because the federation is standards-based. STACKIT IdP can
be the upstream itself rather than a downstream, which is the middle option and the one that
removes the external dependency without adding an identity provider to operate.

Whichever is chosen, the access model on the platform side is the same one [`SEC 5`](/architecture/pillars/security/sec-05-least-privilege/) describes, and
the sovereignty decision here is about the authentication source rather than about authorization.

**Tradeoffs.** **Operational Excellence** and **Reliability**, substantially. Separate identity
estates fragment the account lifecycle, which is where offboarding failures come from.
Self-operated identity providers are critical infrastructure with the availability requirements to
match.

**Verify.** For your Tier 1 workload, which directory authenticates its users? Was that a decision
or the organizational default?

---

## SOV 9.3 Design the recovery path, which depends on identity

**Risk if not established:** High

Identity is the dependency that turns other outages into unrecoverable ones. If authenticating
requires a system that is unavailable, nobody can log in to fix anything, including the identity
system.

The circular case is the one to design for: the federation is down, so administrators cannot
authenticate, so nobody can reconfigure the federation. A break-glass path that does not depend on
the federation is what breaks the circle, and it has to be created before it is needed.

That path is a deliberate exception with the properties [`SEC 5.3`](/architecture/pillars/security/sec-05-least-privilege/#sec-53-make-break-glass-access-fast-bounded-and-reviewed) and [`SOV 5.3`](/architecture/pillars/sovereignty/sov-05-operator-access/#sov-53-constrain-the-support-and-operations-paths) describe: strong
credentials held securely, use that is conspicuous rather than merely logged, and periodic testing
so that it works when it is needed.

Test it on a cadence. A break-glass credential that has expired, that nobody can locate, or that
grants insufficient access is discovered during the incident it exists for.

Include the sovereignty question in the recovery path itself. An emergency path that routes
through a provider outside the boundary is a boundary crossing at the worst moment, and it is the
kind of exception that assessments find.

**On STACKIT.** Where federation is configured, the platform-native path is the fallback that does
not depend on the upstream, and knowing whether that path exists and who holds it is the thing to
establish rather than to assume.

The wider dependency question is [`REL 5`](/architecture/pillars/reliability/rel-05-resilient-interactions/): an identity provider is a dependency whose failure mode
is total, and it deserves the same treatment as any other critical dependency rather than being
assumed available.

**Tradeoffs.** **Security.** A break-glass path is a standing privileged credential, which is a
risk in itself. It is a smaller risk than being unable to recover, and it is why the compensating
controls matter.

**Verify.** If your identity provider were unavailable, who could still authenticate to fix it?
When was that last tested?

---

## SOV 9.4 Include workload identity, not only human identity

**Risk if not established:** Medium

Most access to data is made by workloads rather than by people, and workload identity is
frequently outside the identity architecture entirely.

A service authenticating with a long-lived credential in a configuration file is an identity with
no lifecycle, no expiry and no review. It survives the departure of the person who created it and
it appears in no access review, which makes it the most durable form of access in the estate.

The improvement is short-lived credentials issued to a verified workload identity rather than
static secrets distributed to it. That removes the credential from configuration, gives it an
expiry, and makes the identity revocable.

Include workload identities in access review. They accumulate faster than human ones and they are
never offboarded, which is [`SEC 5.4`](/architecture/pillars/security/sec-05-least-privilege/#sec-54-review-actual-entitlements-against-intended-ones-on-a-cadence) and the reason unused ones persist for years.

The sovereignty relevance is the same as for human identity: whoever issues and validates the
workload's credential decides which workloads may act, and that authority is part of the chain in
[`SOV 6.1`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-61-maintain-a-current-inventory-of-every-party-that-processes-your-data).

**On STACKIT.** <LinkChip href="https://docs.stackit.cloud/platform/access-and-identity/service-accounts/">Service
accounts</LinkChip> are the
platform mechanism for non-human identity, with documented <LinkChip href="https://docs.stackit.cloud/platform/access-and-identity/service-accounts/authentication-flows/">authentication
flows</LinkChip>
and <LinkChip href="https://docs.stackit.cloud/platform/access-and-identity/service-accounts/how-tos/manage-service-account-keys/">key
management</LinkChip>.

<LinkChip href="https://docs.stackit.cloud/platform/access-and-identity/service-accounts/how-tos/manage-service-account-federations/">Service account
federation</LinkChip>
is the more interesting mechanism for this question, because it allows a workload to authenticate
using an identity it already has rather than a distributed key. Where that applies, it removes the
long-lived credential from the design entirely, which is the outcome this practice is after.

**Tradeoffs.** **Operational Excellence.** Short-lived credentials require the workload to handle
renewal and to fail correctly when it cannot, which is application design rather than
configuration.

**Verify.** How many long-lived credentials does your workload hold? For each, when was it
created, who created it, and when does it expire?

---

## Related

- [`SEC 4`](/architecture/pillars/security/sec-04-identity/) Identity, which this supplies the authentication source for
- [`SOV 5.1`](/architecture/pillars/sovereignty/sov-05-operator-access/#sov-51-establish-who-can-technically-reach-the-data-including-the-provider) Access enumeration, which identity decides the membership of
- [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/) Jurisdictional chain, which the identity provider belongs to
- [`SEC 9`](/architecture/pillars/security/sec-09-secrets/) Secrets, which workload credentials are
- [`REL 5`](/architecture/pillars/reliability/rel-05-resilient-interactions/) Resilient interactions, which an identity provider is a critical dependency for