WS-Federation
Everybody remembers Simple Object Access Protocol (SOAP). SOAP was one of the very first protocols whose goal was to standardize communication messages for web services among computers in a network. SOAP uses eXtensible Markup Language (XML) as its message format and leverages protocols such as HTTP for its communication layer because of its great utilization among the most common operating systems, such as Windows, Linux, and macOS.
WS-Federation is part of the WS-Security framework (published by OASIS), which is an extension of SOAP created to standardize the security of web services in terms of the confidentiality and integrity of their messages. WS-Federation’s purpose is to unify the way different realms (which could be different companies or different units within the same company) manage identities and authentication by creating a common way of exchanging user information among their web services.
We know federation is based on trust, but how can we establish trust between two web services? WS-Federation introduced the concept of federation metadata to solve this problem. The federation metadata is an XML file published by a web service to share all the information needed to establish a trust relationship with the realm that the web service belongs to. The web service could be either an IdP or a service provider, and the information in the metadata differs according to which role the web service has:
- In an IdP, the typical information within the federation metadata file includes claims definitions, the IdP identifiers and endpoints, and the public keys of the certificates used to sign and encrypt the responses and the tokens issued by the IdP’s STS (defined in the WS-Trust specification, also part of the WS-Security framework)
- In a service provider, the typical information includes the service provider identifiers and endpoints and the public keys of the certificates used to sign and encrypt the requests to the IdP’s STS
Once a federation has been established and the parties have exchanged the information, users belonging to the realm where the IdP is located can start using web services provided by the realm where the service provider is.
There are two ways (or profiles, as defined within the protocol specification) to implement an authentication flow: the WS-Federation Passive Requestor Profile and the WS-Federation Active Requestor Profile, which will be briefly described next.
WS-Federation Passive Requestor Profile
A web browser, the Passive Requestor Profile, tries to access the web service resource that requires the requestor to be authenticated. If the requestor hasn’t already obtained proof of authentication, then it is redirected to its identity provider’s STS where, after successful authentication, it will obtain a security token. This security token will be redirected to the web service resource, which will decide whether to authorize access based on the information included in the token.
This flow is a typical service-provider-initiated flow, where the passive requestor tries to access the service provider directly. A slightly different flow, called the identity-provider-initiated flow, starts with a web browser (the passive requestor) accessing the IdP first but specifies in the request the web service resource (the service provider) it would like to be redirected to after successful authentication.
WS-Federation Active Requestor Profile
WS-Federation added the Active Requestor Profile to support all those clients that behave as active requestors. An active requestor (which could be a native application running on Windows or Linux), unlike a web browser (a passive requestor), which passively follows the redirections provided by the web service resources it would like to access, collects the information needed for the authentication first (typically, the username and the password of a user) and then it sends them directly to the identity provider’s STS to obtain a security token that can later be used to get access to the web service resource (the service provider) if the user is authorized. The IdP usually exposes a dedicated HTTP endpoint to enable this flow.
In the next section, we will focus on another important authentication protocol: SAML.