Trust relationship

A trust relationship lets one domain rely on identities another domain has authenticated. In federated identity, the trust is set up in advance between an identity provider and a relying party, which commonly exchange federation metadata, including signing certificates. When a SAML assertion or token arrives, the relying party accepts it because it verifies against a key the trust already established, not because of anything in the live request.

Directory services use the same idea between domains, commonly described by direction and transitivity. In a one-way trust, the trusting domain accepts accounts from the trusted domain, so the trusted domain’s users can reach the trusting domain’s resources but not the reverse; a two-way trust works both ways. A transitive trust extends along a chain, so if A trusts B and B trusts C, A also trusts C; a non-transitive trust does not. Transitivity is convenient and also a risk, because a compromise in one domain can travel along the chain.

Exam relevance: a scenario is likely to ask, given a trust’s direction, whose users can reach whose resources, or to present transitive trust as an attacker’s path. Candidates are expected to follow direction carefully and to recognise that federation trust rests on keys exchanged beforehand, which is why a stolen signing key, as in Golden SAML, is so damaging.