Royal Army College

Lesson Overview

Lesson 01 called identity the master key, and CIS 210 showed how a single identity service signs a person in across many systems. This lesson takes that arrangement, single sign-on built on identity federation, and examines it from the security side: how one identity is trusted across many systems, what that web of trust gains and risks, and how it is secured. Federated single sign-on is one of the most powerful things a small force can do with identity, letting a few people manage one set of accounts that work everywhere instead of a separate account on every system, but it concentrates trust in a way that is both its great strength and its great danger. This lesson is about understanding and securing that concentration, so that the convenience of one identity everywhere does not become the catastrophe of one compromise everywhere.

The governing idea is that federation concentrates trust, which is its power and its peril, and the concentration must be secured accordingly. When many systems trust one identity provider to vouch for who a user is, a person signs in once and is known everywhere, which is wonderful for the user and for the small team managing accounts; but it also means that the identity provider becomes the single point on which all those systems' security depends, so its compromise is the compromise of everything that trusts it, and the trust relationships between the provider and the systems become things that must themselves be protected. So federated single sign-on is to be embraced for what it gives a small force, one well-managed identity everywhere, and secured for what it concentrates, the trust that, if broken, breaks everything. The member who understands both sides can build and support federation that delivers its convenience without surrendering to its peril; one who sees only the convenience builds a single point of catastrophic failure.

This is the knowledge layer; the practice of running federation and single sign-on is done under those who administer the estate, with access following appointment. It rests on recognised identity-federation practice and reflects the Principality's own single-sign-on reality, and is wholly defensive. Read this to understand federation and its security; the practice comes under guidance.

By the end you will be able to explain federation and single sign-on and how one identity is trusted across many systems, weigh the benefits and the concentrated risk of federation, secure the identity provider and the trust relationships, understand federation with external and partner systems, and apply these to a small force's identity estate.

Key Terms

Federation: an arrangement in which separate systems trust a common identity provider to vouch for who a user is, so one identity works across them all.
Single sign-on (SSO): the user experience federation enables, signing in once to the identity provider and being known to many systems without signing in again to each.
Identity provider (IdP): the central service that holds identities and authenticates users, which the other systems trust to vouch for them.
Relying party (service provider): a system that relies on the identity provider to authenticate users, trusting its word about who a user is.
Trust relationship: the configured trust between the identity provider and a relying party, by which the service accepts the provider's word; a thing that must be protected.
Concentration of trust: the way federation makes many systems depend on one identity provider, gaining manageability but creating a single critical point.
Token (assertion): the secure proof the identity provider issues to vouch for an authenticated user to a relying party, which must be protected from forgery and theft.
Federation with external parties: extending trust to or from systems outside the force, such as partners, which brings reach and added risk.
Single point of failure: a component whose failure brings down much that depends on it; the identity provider is one for everything that trusts it.
Defence of the identity provider: the strong protection of the central identity service, because the security of all federated systems rests on it.

Federation and single sign-on

To secure federation you must first understand plainly what it is. Federation is an arrangement in which many separate systems agree to trust a common identity provider to authenticate users and vouch for who they are, so that instead of each system holding its own accounts and passwords, they all rely on the one provider's word. Single sign-on (SSO) is what this gives the user: they authenticate once, to the identity provider, and are then known to every system that trusts that provider, signing in to many systems through one identity without a separate login for each. The systems that rely on the provider are the relying parties; the trust between each of them and the provider is a configured trust relationship; and the secure proof the provider issues to vouch for a user is a token or assertion the relying party accepts.

The mechanics matter less than the shape, which the member should hold clearly: one identity provider in the centre, many systems around it trusting its word, one identity per person working across all of them. A person has one account at the identity provider; that one account, through the trust relationships, signs them in everywhere; and the force manages that one set of accounts in one place rather than a separate set on every system. This is the arrangement the Principality runs, a central identity service signing members in across its systems, and it is the natural and powerful way for a small force to manage identity across many systems, because it turns the impossible task of managing separate accounts on dozens of systems into the manageable task of managing one identity per person centrally.

This is why federated single sign-on is so valuable to a small force, and the benefits are real and worth stating. One account per person, managed in one place, means the lifecycle of Lesson 02, joiner, mover, leaver, is done once and applies everywhere: create the account once and the person has access across the systems; remove it once and their access is gone everywhere, which is far safer than hunting down separate accounts on every system and missing some. Consistency: access and identity are governed uniformly from the centre rather than diverging across many systems. And convenience: the user signs in once, which, beyond being pleasant, encourages good security because it makes strong central authentication (MFA at the provider) cover everything. For a small team managing the identity of a whole digital state, federated SSO is close to essential, which is why understanding it is core to this course.

The concentration of trust: power and peril

The same feature that makes federation powerful, that everything trusts one identity provider, is what makes it perilous, and holding both sides at once is the heart of this lesson. The concentration of trust is the gain: by centring identity on one provider, the force gets one account per person, one place to manage it, one set of strong controls (MFA, monitoring) protecting access to everything, and the clean lifecycle that removes a leaver's access everywhere at once. This concentration is exactly what lets a small team manage identity across a large estate, and it is a genuine security gain in many ways, because central control is far easier to do well than scattered control across many systems each with its own accounts.

But the concentration is also the peril: because all those systems depend on the one identity provider, the provider becomes a single point of failure for everything that trusts it. If the identity provider is compromised, the attacker can potentially impersonate any user to every relying party, because the systems trust the provider's word, so a compromise of the central identity service is not the compromise of one system but of all of them. If the provider is unavailable, no one can sign in to anything that depends on it, so its failure can lock the force out of its whole estate. And the trust relationships and tokens themselves become things an attacker may try to forge or steal, because a forged token or a subverted trust relationship lets an attacker be accepted as an authenticated user without compromising the provider directly. The concentration that gives the force one identity everywhere gives an attacker, potentially, one target for everything.

The resolution is not to abandon federation, whose benefits a small force cannot do without, but to secure the concentration in proportion to its criticality. Because so much depends on the identity provider, it is protected with corresponding strength; because the trust relationships and tokens are valuable, they are secured; because the provider is a single point of failure, its availability and recoverability are planned. Federation is embraced for its power and hardened for its peril, which is the disciplined stance, and the rest of the lesson is how that hardening is done. The member holds the balance: federation is right for a small force, and precisely because it concentrates so much, it must be among the most strongly secured things the force runs.

   FEDERATION: ONE IDENTITY EVERYWHERE  (power and peril together)

        many RELYING PARTIES (systems)
              \    |    /
               \   |   /   each TRUSTS the provider's word (trust
                \  |  /     relationships; tokens vouch for users)
            IDENTITY PROVIDER (IdP)  <-- one account per person; SSO
                 |
            one person signs in ONCE, is known EVERYWHERE

   POWER (concentration of trust): one account to manage; lifecycle done
     once applies everywhere; strong central controls cover all
   PERIL (same concentration): the IdP is a SINGLE POINT OF FAILURE,
     compromise = impersonate anyone everywhere; unavailable = locked out
     of everything; tokens/trust can be forged or stolen

   -> Don't abandon it; SECURE the concentration in proportion.

Securing federation

Securing federated single sign-on follows from where its risk lies: above all in the identity provider, then in the trust relationships and tokens, then in the provider's availability. The defence of the identity provider is the first priority, because the security of everything that trusts it rests on it: the identity provider gets the strongest protection the force can give, the strictest hardening (Lesson 08... CIS 210's hardening), the strongest authentication on its own accounts (MFA always, especially for its administrators), the closest monitoring, and the privileged-access discipline of Lesson 06 at its most rigorous, because administrative access to the identity provider is the most powerful access in the whole estate, the access that controls the master key itself. A force that protects its identity provider as the critical asset it is has secured the foundation of all its federated access; one that protects it casually has left the keystone weak.

The trust relationships and tokens are secured so they cannot be forged or abused: the trust between provider and relying parties is configured carefully and protected, so an attacker cannot insert a false trust or subvert a real one, and the tokens the provider issues are protected from forgery and theft (by the cryptographic protections federation standards provide, and by guarding the secrets and keys, Lesson 04, that underlie them), so an attacker cannot mint or steal a token to impersonate a user. The relying parties, too, are configured to trust only the genuine provider and to validate the tokens they receive, so the web of trust holds. And the provider's availability and recoverability are planned, because it is a single point of failure: it is made resilient and is backed up and recoverable (Lesson 05 and CIS 310), so that its failure does not permanently lock the force out of its estate, and so it can be restored if compromised or lost.

Through all of it runs the framework rule the course keeps returning to: access follows appointment, not qualification, and federation makes this rule both easier and more important to enforce. Easier, because with one central identity, an appointment's access can be granted and, crucially, revoked in one place and apply everywhere, so a leaver's access vanishes across the whole estate at once rather than lingering in forgotten accounts. More important, because the central identity is so powerful that getting its lifecycle right, promptly removing access when appointments end, especially privileged access to the provider itself, matters more than anywhere else. Federation secured, the provider defended, the trust and tokens protected, availability planned, and the lifecycle enforced centrally, gives a small force the great benefit of one identity everywhere with the concentration's peril held in check, which is exactly the balance this lesson seeks.

Federation with external parties, and the small force

A final dimension is federation with external parties: extending trust beyond the force's own systems, to or from partners, so that, for instance, the force's members might access a partner's system through the force's identity, or partners might be granted identities the force's systems trust. This brings real reach, letting a small force interoperate with partners without managing separate accounts everywhere, which connects to the interoperability and reach-back themes of the signals courses. But it also extends the web of trust outside the force's control, which adds risk: trusting an external provider means trusting its security, and being trusted by external systems means one's own provider's compromise reaches them too. So external federation is entered deliberately and carefully, with attention to whose security one is trusting and what the trust exposes, and limited to what is genuinely needed, the minimisation principle applied to trust relationships themselves.

For a small force, the practical stance on federation is the same balance the lesson has drawn throughout, applied within its means. The force uses federated single sign-on for its own estate, because it is the only manageable way for a few people to govern identity across many systems, and gains the lifecycle, consistency, and central-control benefits. It secures the concentration by protecting the identity provider as its most critical asset, with strong authentication, hardening, monitoring, and the strictest privileged-access discipline, and by guarding the trust relationships, tokens, and the provider's availability, which are achievable even for a small team because they centre on protecting one critical service well rather than many. And it federates externally with care, only where needed and with awareness of the trust it extends. The member who understands that federation is both the small force's great identity enabler and its most concentrated risk supports it wisely, getting the convenience of one identity everywhere while keeping the catastrophe of one compromise everywhere at bay, which is what securing federation is for.

In Practice: One Identity, Strongly Guarded

A member of the Royal Kaharagian Army supporting the Principality's identity studies how its federated single sign-on is run, and sees the lesson's balance in action: federation embraced for the power a small force cannot do without, and secured for the peril its concentration creates. A naive approach would enjoy the convenience of one identity everywhere while protecting the central identity provider no more than any other system; the disciplined approach guards the concentration in proportion to its criticality.

The Principality runs a central identity provider that signs members in across its systems by single sign-on: one account per person, managed in one place, so the lifecycle is done once and applies everywhere, create the account and the member has access across the estate, remove it and their access is gone everywhere at once, far safer than scattered accounts. The member appreciates this concentration's power: one identity to govern, strong central MFA covering everything, clean revocation. But they understand its peril equally: the identity provider is a single point of failure, whose compromise could impersonate anyone everywhere and whose loss could lock out the whole estate.

So the provider is defended as the most critical asset it is: the strongest authentication on its own accounts, MFA always and especially for its administrators; the strictest hardening and closest monitoring; and the privileged-access discipline of the previous lesson at its most rigorous, because administrative access to the identity provider controls the master key itself. The trust relationships and tokens are protected from forgery and abuse, the relying parties trusting only the genuine provider and validating its tokens, and the provider's availability and recoverability are planned so its failure is not permanent lockout. External federation with partners is entered only where needed and with care for the trust it extends. And throughout, access follows appointment, enforced centrally so a leaver's access vanishes everywhere at once. The Principality gets the great benefit of one identity everywhere, with the concentration's danger held in check, because its few identity managers secured the one critical service well, which is exactly how a small force should run federation.

Check Your Understanding

Explain federation and single sign-on, the roles of the identity provider and relying parties, and the shape of "one identity everywhere." Why is federated SSO so valuable to a small force (one account per person, lifecycle done once, consistency, convenience)?
Explain the concentration of trust as both the power and the peril of federation: what it gains, and why the identity provider becomes a single point of failure whose compromise or unavailability affects everything that trusts it (and the risk to trust relationships and tokens).
Describe how federation is secured: defending the identity provider as the most critical asset (strong auth, hardening, monitoring, strictest privileged-access discipline), protecting the trust relationships and tokens, planning the provider's availability, enforcing the lifecycle centrally, and federating with external parties carefully.

Reflection (write a short paragraph): This lesson argues that the very thing that makes federation powerful, that everything trusts one identity provider, is what makes it perilous, so the concentration must be secured in proportion to its criticality. Why is it tempting to enjoy the convenience of single sign-on while protecting the central identity provider no more strongly than an ordinary system, and what would that leave exposed? Then think about the benefit that a leaver's access can be removed everywhere at once from one place: why is that centralised lifecycle both a major security gain and a reason the identity provider must be guarded above all?

Summary

Federation has many systems trust a common identity provider to authenticate users, giving single sign-on: one account per person, signed in once and known to all relying parties. This is the natural, powerful way for a small force to manage identity across many systems, and it is what the Principality runs.
Federated SSO's benefits are real: one account per person managed centrally (so the lifecycle, joiner-mover-leaver, is done once and applies everywhere, removing a leaver's access everywhere at once), consistency, and convenience that lets strong central authentication cover everything.
The concentration of trust is both power and peril: the gain is central, manageable, strongly-controlled identity; the peril is that the identity provider becomes a single point of failure, its compromise able to impersonate anyone everywhere, its unavailability locking out the whole estate, and its trust relationships and tokens targets for forgery or theft. The answer is not to abandon federation but to secure the concentration in proportion.
Secure federation by defending the identity provider above all (strongest authentication, hardening, monitoring, strictest privileged-access discipline, since admin access to it controls the master key), protecting the trust relationships and tokens from forgery and abuse, planning the provider's availability and recoverability (single point of failure), and enforcing access follows appointment centrally. Federate with external parties only where needed and with care for the trust extended.
This is the knowledge layer; running federation and SSO is done under those who administer the estate, with access following appointment. The lesson takes the SSO of CIS 210 from the security side, applies the privileged-access discipline of Lesson 06 to the provider, the secrets of Lesson 04 to its tokens, the lifecycle of Lesson 02 enforced centrally, and connects to the resilience of Lesson 05 and CIS 310. Everything here is defensive.

Federation, Single Sign-On, and Trust Between Systems