Federated identity, the core branch of identity management, is a system that links a user’s credentials and online identity. This allows them to sign in to different computers or systems which recognize such attributes. Web services federation is a concept that comes under the federated identity. But why is WS-fed used?
Web services federation is a tool for federated identities to transfer user credentials or even authentication attributes across different security environments. One can request access to a different application (which works on different security) and get authenticated through WS-fed.
How to use web services federation for transferring identity?
Everything starts with a request from the end-user to access another application, server, or SaaS product. These are often protected by particular identity federation servers (like SP federation server), which checks if the user has a WS-fed trust token from an STS provider. If this is not found, the end-user has to generate a token from a trusted STS provider after it validates and authenticates the user’s identity. However, if the end-user has gained access in the past, its credentials will be saved in the LDAP(Lightweight Directory Access Protocol) or AD( active directory). A SAML 1.1 assertion is generated using this information, which is transferred to the SP server over the web browser. As the end-user has logged in before, there must be a pre-established WS-fed trust used by the SP federation to begin a session for the user for a given time as per rules.
The concept of Identity federation and WS-fed is engraved in almost all online web browsers, servers, applications, and SaaS products as WS-fed restricts the creation of new user credentials every time they sign into different domains. For instance, when filling out an application, the page often becomes unavailable after a given time as the SP federation of that system has a fixed period given to end-users.