Home > Security > Federated access control through Windows Identity Framework (WIF) Part 1

Federated access control through Windows Identity Framework (WIF) Part 1


In this post, I will introduce the concept of the federated access control to different resources using the Windows Identity Framework (Geneva framework) delivered by Microsoft. The purpose of this first part is to introduce the concept of the federated authentication.

First of all, let’s imagine the following scenario: You are usually using X.509 certificates technology to access to the resources of your enterprise but in an other enterprise, where you are obliged to spend some days, you won’t be able to use the same resources since they use an other technology like Kerberos for example.

Assuming that you are not obliged to implement the Kerberos technology, so how will you be capable of consuming the services of the new enterprise?

The federation principle is aiming to resolve that problem by federating existing protocols and even future ones.

Secondly, the claims based authentication is a new concept where different credentials used for authentication are considered as claims contained into a serialized structure named token.

The federation principle is based on the concept of the CBA (Claims Based Authentication) through three roles as illustrated in the following image :

 

  1. The user is the entity aiming to consume a service through a passive browser or a thin client.
  2. The identity provider (IP) which is implementing a special service to deliver tokens according to Relying Party policies to the User after authentication. This special service is implementing WS-Trust endpoints and is named Security Token Service (STS).
  3. The application which delivers services to User.

So for our first scenario, the User consults the policy of the application and knows that is requiring a Kerberos ticket. The User generates a Request Security Token to the IP. The IP after authenticating the user (by Certificates) delivers to him a signed token containing the requested kerberos ticket. The user sends finally the generated token to the application which can verify the identity of the IP thanks to its signature.

Finally, the application can rely on a local rules engine or an external process to manage the authorization of the user.

Advertisements
Categories: Security Tags: , , ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: