Network Federation

The notion that a network needs to be accessible to more than just a well-defined group of employees.

Organizations might need to open parts of it network to partners, suppliers, and customers. It's relatively easy to manager your own employees, but managing accounts for suppliers and/or customers might be a little harder. This is where federation comes in. Federation means that the company trusts and grants (limited) access to user accounts from other domains/networks. This is most commonly implemented by allowing account creation using a Google Workspace, Facebook (Meta), or Twitter account.

On-premises networks often use things like LDAP and Kerberos in tandem with Active Directory to centralize management of both user accounts and devices. However, using federation comes with other issues, because you're now implementing interoperability between different platforms. For example, web apps might not support Kerberos, and third-party networks might not support a direct federation implementation with LDAP or AD.

Claims-based Identity

This is where claims-based identity comes in. While technical implementation and terminology varies, the overall structure is similar to Kerberos' SSO. 

• The principal tries to access a service, which redirects the principal to an identity provider (IDP).
• The principal authenticates with the identity provider and obtains a claim in the form of a token/document signed by the IDP.
• The principal presents the claim to the service provider, who validates the claim using a pre-configured trust relationship with the IDP.
• The service provider now connects to it's accounts database to determine user attributes and permissions. It might even be able to query attributes of the user's profile held by the IDP if the principal has allowed this.

These claims are often written in SAML, which is based off of eXtensible Markup Language (XML). Communications are established using HTTP/HTTPS and something called Simple Object Access Protocol (SOAP). Secure tokens that need to be shared are signed according to the XML signature specification.

Open Authorization (OAuth)

OAuth is an open protocol based on representational state transfers (REST) rather than SOAP. RESTful APIs are sometimes preferred due to the loose implementation standards that organizations can tailor configurations to best match their needs. Additionally, compared to SOAP and SAML, OAuth has better support for mobile apps that require federated authentication.

The OAuth protocol is designed to facilitate the sharing of information (resources) within a user profile between sites. To start, users create an account with the IDP that is password-protected. That identity can then be linked with services that user OAuth without giving the password to said site. Sites must be registered with the IDP in this case, and must have specific endpoint information.

• Redirect URL: The endpoint where the IDP takes over authentication and processes authorization tokens.
• Service ID
• Service Secret

The IDP is responsible for managing different ways users can authenticate using specified processes called flows. At the end of the flow, the client ends up with a validated access token that the service can verify and accept.