Federation

---

Federation is a process that provides a shared login capability across multiple systems and enterprises.

• aka federated identity management
• essentially connects the identity management services of multiple systems
• is the notion that a network needs to be accessible to more than just a well-defined group of employees
• on-premises network can use technologies such as LDAP and Kerberos
  • often implemented as a Windows Active Directory network
  • because the administration of accounts and devices can be centralized
• Identity provider (IdP) is the entity that provisions and authenticates identity assertions
• relying party is any member of the federation that shares resources based on authenticated identities
  • handle authorization based on their own policies

Example

• e.g.,
  • in business,
    • a company might need to make parts of its network open to partners, suppliers, and customers
    • federation means that the company trusts accounts created and managed by a different network
  • in consumer world,
    • user might want to use both Google Workspace and Facebook
    • if Google and Facebook establish a federated network for the purpose of authentication and authorization
      • then the user can log on to Facebook using their Google credentials or vice versa

How Federation Works

• When implementing federation,
  • authentication and authorization design has:
    • more constraints
      • web apps may not support kerberos
    • additional requirements to ensure interoperability between different platforms
      • third-party networks might not support direct federation with AD
  • requires use of standard protocols or frameworks for interoperability between web applications
• interoperable federation protocols use claims-based identity

  • overall model is similar to that of Kerberos SSO:

    1. A service provider (SP) establishes a trust relationship with an identity provider (IdP)
    2. The principal attempts to access a service provider
    3. The service provider redirects the principal to the IdP
    4. The principal authenticates with the identity provider
    5. If authentication is successful, the principal obtains a claim, in the form of some sort of token or document signed by the IdP
    6. The principal presents the claim to the service provider
       • SP can validate that the IdP has signed the claim because of its trust relationship with the IdP

    

  • service provider can now connect the authenticated principal to its own accounts database

    • to determine permissions and other attributes
    • may be able to query attributes of the user account profile held by the IdP
      • if principle has authorized this type of access
• federated network or cloud needs specific protocols and technology to implement
  • user identity assertions
  • transmit claims between the principal, the service provider, and the identity provider

Trust

In planning authentication and authorization, a trust model defines the relationships between authentication services so that they may accept each other’s assertions of users’ identities and permissions, when appropriate.

• Trust models determine how organizations establish relationships among authentication services to authorize different users and groups access to various resources
• Trust relationships across different authentication domains are described in terms of:
  • direction
    • one-way
    • or two-way
  • transitivity
    • trust relationships transfer across domains
    • either transitive or nontransitive
      • in nontransitive trust, domain admin must explicitly trust other domain
    • e.g.,
      • if domain 1 trusts domain 2
      • and domain 2 trusts domain 3
      • then domain 1 will trust domain 3
    • peer trust models avoid a single point of failure
      • but are more complex
    • Active Directory can implement peer trust between domains