Working of WS-Fed

Single Sign-On (SSO) is the key to Access Diversity. While SSO allows a single authentication credential to access different systems within a single organization, Federation provides single access to multiple systems across different enterprises. WS-Federation, OAuth and SAML are some of the frameworks which are used for implementing federation in an organization.

The WS-Federation framework builds on three main specifications:

• WS-Security: The specification provides the basic mechanisms for securing SOAP messages. This standard provides for the following to Simple Object Access Protocol (SOAP) messages:
  1. Integrity (XML Digital Signature with SOAP)
  2. Confidentiality (XML Encryption with SOAP)
  3. Transmitting identity tokens actors (Username Tokens, SAML2, Binary Security Tokens, etc)

Passive request profiles use this to create a base for using WS-Trust for further communication. Active request profiles (who can build their own SOAP hence no browser redirection) don’t need this protocol and directly deal with WS-Trust and WS-Security.

• WS-SecurityPolicy: It is a security add-on to the WS-Policy. It defines a set of security policy assertions and a framework for allowing web services to express their constraints and requirements.

• WS-Trust : It builds on the WS-Security base by –
  1. Providing additional mechanisms for working with security tokens and defines the communication with a Security Token Service (STS).
  2. WS-Trust clients can make different types of calls for the exchange of security tokens.

Security token service (STS) is a generic service that issues/exchanges security tokens using a common model and set of messages. As such, any Web service can, itself, be an STS simply by supporting the WS-Trust specification. 

Identity Provider (IdP) performs peer entity authentication and can make identity claims in issued security tokens. User agent obtains an identity security token from its IP and then presents/proves this to the STS for the desired resource. Most of the time, IdP and STS are used interchangeably.

According to the number of IdPs on either side of the communication, there can be two scenarios:

• Both User Agent and Resource use an IdP.
• Only the User agent uses an IdP

IdP/STS use Attribute and Pseudonym services which provide specific attributes needed for authentication(attribute service) or different aliases(pseudonym service) associated with the user agent .

There can be scenarios where the Attribute and Pseudonym services are separated from the IdP/STS service , where an extra step of getting the aliases or attributes from a different system is added.

The WS-Federation specification describes the following actors in the Passive Requestor Profile:

• User Agent: a web client, typically a web browser, that is interacting with the Resource and IdPs.
• Resource: A protected web endpoint that relies upon the IdPs for authentication and authorization of the Requester.
• Resource IdP/STS: The IdP/STS that the Resource trusts.
• User agent’s IdP/STS: The IdP/STS that owns the Requestor’s credentials. Has a trust relationship with the Resource IdP/STS.

The working is very similar to that of SAML and only the parameters used for building the trust and tokens are different . The steps for SSO using WS-FED include (Figure 3a):

1. Requesting the target resource.
2. SP Determines the IdP and redirects to the SSO Service at the IdP containing the RST(Request Security Token).
3. For validating the user agent, IdP parses the RST.
4. The IdP then generates a Request Security Token Response (RSTR) and sends it back to the resource.
5. The assertion consumer processes the response and redirects the user agent to the resource (login done) at SP.
6. Requesting the specific target resource again (specific page or document on the resource)
7. Response of the resource at SP for the request from the user agent.

If both the resource and user agent are using IdP/STS, then the sequence of events will be different as depicted in the figure below –

How can we help?

Delegating the authentication of multiple applications through a single IDP for centralizing the authentication process. It brings control over access and security to a single centralized point. It provides different advantages such as password policies and management, access control, easy account deactivation, logging, auditing, monitoring and alerting, Compliance, and control.

There are different scenarios and configurations of implementing Federation depending upon the network architecture of the organization. Choosing the best for your organization and maintaining the standards and versions as and when required is a necessity. We at SecurDI, are team professionals who have been working in this field for more than 15 years and can help you gauge the different options and vendors available to choose and implement the best suited for your needs. We can also help you operate your solution, providing insights and enhancements along the way to ensure you have a robust, resilient, and future-proofed solution.

– Authored by Gayatri Priyadarshini

Office photo created by rawpixel.com – www.freepik.com