Preamble

This is the first post in a series about decentralized identity, access control management and the claims model. The remaining posts are available here:

• Alice in Claims: the claims model
• Alice in Claims: protocols
• Alice in Claims: the anatomy of a token
• Alice in Claims: not only for federation
• Alice in Claims: Windows Identity Foundation
• Alice in Claims: the WIF claims class model

Introduction

Last April I gave a session at the Portuguese TechDays event about Claims based identity management and the Windows Identity Foundation (WIF).

In this series of posts, I will reproduce its main content.

The scenario

Consider the scenario where a software company (WeDev) is developing a software project for a customer (WeUse).

For managing issues (e.g defects, feature requests), they are using a cloud based issue tracking system (CloudTrack).

Alice is a lead developer at WeDev, and one of her tasks is the management of issues created by WeUse employees, such as Bob.

Alice accesses the CloudTrack web app

In a classical scenario, when Alice accesses the CloudTrack web app, the following steps are performed:

• First, Alice needs to prove that she is Alice. For that, she uses a set of credentials such as a username-password pair.
• One of Alice’s roles is LeadDev and all WeDev’s lead developers can manage issues, that is, all lead developers have the IssueMgr role.
• Finally, all issue managers can view issues (have the IssueView permission), so Alice is granted authorization to access the issue view endpoint.

On a centralized scenario, a typical .NET based implementation is based on the following:

• A membership provider is used to validate the credentials and fetch the name of the user accessing the web app.
• Then, a role provider is used to obtain the user’s roles, which for Alice are LeadDev, IssueMgr and IssueView.
• Finally, the accessed endpoint checks if the user has the IssueView role (e.g. via an imperative or declarative principal permission demand or via the URL authorization module).

Decentralized Authority

One of the problems with this centralized solution is the usage of  information whose authority is decentralized. Notice that Alice is accessing the web app as a WeDev employee not as a CloudTrack client: WeDev is the authoritative source of this identity, not CloudTrack. Probably, WeDev already has an identity management infrastructure for its employees.

In other words, in this centralized solution, the CloudTrack web app is storing and managing identity information for which is not the authoritative source. This mismatch is the cause of many identity management problems:

• Alice must have a separate credential set for the CloudTrack’s web app, with the associated usability and security problems. CloudTrack also gets the burden of providing all the standard credential management functionalities (e.g. password modification, protection against dictionary based attacks).
• Alice’s roles must be explicitly created and managed in the CloudTrack web app. Namely, any changes in her WeDev roles must be synchronized into the CloudTrack web app.

The root of these problems is the decentralized authority of Alice’s identity information:

• Alice’s credentials and roles are under WeDev authority, not CloudTrack’s. However, this information must be consumed by CloudTrack’s webapp, causing this replication problem.
• Not all identity information used in the access is under WeDev authority. Alice’s authorization decisions (e.g. the IssuerMgr role and IssueView authorization) only make sense in the web app scope.

Concluding:

• The CloudTrack web app should not have to store Alice’s credentials and identity information.
• There should be a way to communicate the relevant identity information, namely the LeadDev role, from its authoritative source  (WeDev) to where it is required(CloudTrack web app), only when needed.

In the next post, we will see how the claims based model addresses this scenario.