Understanding Federation with Windows Identity Foundation
The purpose of this blog is to review general concepts and specifications related to Federation. I will start by defining concepts such as authentication, authorization, claims-based architecture, and federated security architecture. Then, I will briefly explain implementations of federation such as Windows Identity Foundation and some alternatives. This is not a technical document showing code on how to implement these concepts.
Let’s First Understand Authentication and Authorization
Authentication is a process to validate a person’s identity. Authorization is a process to determine what a person can do.
John is Sr. Developer for Acme company and wants to review his employee profile using the Human Resources website.
John is first redirected to a login page where he needs to enter his credentials (i.e. user, password, questions, 2FA). He was able to login successfully and is redirected to the Human Resource Home Page. John reviews his employee profile and notices that his job title is incorrect. He attempts to correct the error but he is not allowed to do so. John contacted the HR Manager to correct the job title for him.
In the previous example, John was authenticated to access the HR website by providing the right credentials but he was not authorized to make job title modifications because only HR Managers can do that.
Though authentication and authorization are two different process, we can use both by first authenticating to recognize the user and then authorizing to determine the user’s permissions.
What Are We Trying To Solve?
We do not want to have authentication logic within our applications. One of the reasons is that we do not want to change our application every time the authentication logic changes.
For example: what if we need to move our data from SQL to MySQL or what if we need to move from Dapper to Entity Framework, or what if we want to allow users to login using their social media account?
Imagine that you have a UI that currently asks for username and password but now your authentication process requires the user to answer some questions. You would have to change the logic and design in your UI to implement that authentication requirement.
One of the solutions to this problem is to use an architecture that supports claims-based authentication.
We can create another entity or layer of abstraction dedicated to authentication logic. This new layer would not have any UI logic. It would only have logic related to user claims such as user information and permissions.
- The user or service that needs to be authenticated
- The web application or web service delegating authentication
- The identity provider that manages the authentication logic (Secure Token Service)
- The set of claims returned by the identity provider after successful authentication
- The token including the set of claims for an authenticated user
As a .NET developer, I have worked with different implementations of IIdentity and IPrincipal.IIdentity: Windows, Active Directory, or Forms Authentication. We used to be restricted to a role-based access using a method in the IPrincipal called IsInRole. We could only determine whether a user belongs to a role (a group of users).
Using claims-based authorization eliminates the limitations of the role-based access. Not only we can use roles to determine access, but we can use other user information such age, bank account type, patient type, etc. The good news is that we can use claims-based access since .NET 4.5.
var claims = System.Security.Principal.WindowsIdentity.GetCurrent().Claims;
I will not go any deeper on the claims subject. We could could have covered more about types of security tokens in .NET but my intention is just to define some general concepts before arriving to Windows Identity Foundation, a Federation implementation.
Federated Security Architecture
This is similar to the claims-based architecture but with different terminology. Compare the following list of participants with the previous list in the claims-based architecture.
- Domain or realm: single unit of security administration and trust
- Federation: multiple security domains establishing trust for granting resources
- Security Token Service (STS): A web service that issues security tokens
WS-Federation, Web Services Federation, is an Identity Federation specification that defines common infrastructure that is helpful for the federated identity implementation in passive (web browsers) or active clients (web services).
Windows Identity Foundation (WIF)
After clarifying some important terminology, we can finally arrive to our WIF subject.
Windows Identity Foundation is the technology that Microsoft uses for encapsulating logic for WS-Federation.
Since .NET 4.5, WIF is part of the .NET framework package allowing easier claims implementation for when using .NET applications.
- System.Security.Claims : manages classes related to claims
- System.IdentityModel: acts as the Federation in the WS-Federation protocol
- System.IdentityModel.Services: acts as the STS in the WS-Federation protocol
- Facilitates the creation of claims-aware applications providing claims models and APIs for determining authentication.
- Provides consistency when working with ASP.NET and WCF environments
- There are Visual Studio Templates using WIF helping beginners to understand and implement claims-aware applications.
- Creates an environment where a claims-aware application can interact with third party components such as Service Token Services. For example we can allow users to authenticate via Google, Facebook, Amazon and other providers.
- Facilitates the easy creation of Service Token Services using WIF
- You have control over users logins and passwords
Follow the WS-Federation protocol by using an STS for authenticating your application. Mobile applications, native or not, should connect to an STS to eliminate technology limitations provided by WIF.
Some Alternatives for WS-Federation Implementation
- OpenID or OpenID Connect: OpenID an open standard for authentication providing a framework for connecting identity providers (i.e. Google) and relying parties (i.e. your website). OpenID is the latest version of OpenID and combines authentication with OAuth2 authorization. This is best suited for SSO on consumer apps.
- OAuth2 is an open standard for authorization that allows users to approve tokens to be issued by an identity provider. This alternative is best suited for API authorizations.
Visit my personal site to review some of my demos related to Windows Identity Foundation and other topics. The following demos are related to this blog:
- Google Authenticator: This uses Google Authenticator as part of a authentication process.
- Basic Authorization: This is to simply demonstrate how we can use WIF to identify if a user is authorized or not. In this demo, only authorized users can access a private page. Unauthorized users can access only public pages.
Other related demos coming soon:
- Custom Security Token Service using WIF: Web application used to validate user’s credentials and to return a token for authenticated users.
- OpenID STS Project: Building an STS using OpenId
- MVC Site Consuming OpenID