Monthly Archives: June 2010

Alice in Claims: the claims model

Introduction

This is the second post of a series about claims based identity management and the Windows Identity Foundation (WIF).

The first one presented a scenario with decentralized identity authority. This posts uses this scenario to introduce the claims based model.

The following figure serves two goals:

· It presents the main claims model concepts, and

· Concretizes this concepts in the presented scenario

TheClaimsModel

Claims model concepts

  • Identity is represented by a set of claims, where a claim is a declaration made by an entity. In this scenario, Alice, LeadDev, IssueMgr and IssueView are examples of claims that represent’s Alice’s identity.
  • An Identity Provider (or Issuer) is an entity that issues identity claims, typically containing information for which it is authoritative. In this scenario, WeDev is the identity provider, and it issues name and role claims (e.g Alice and IssueMgr).
  • An Identity Consumer (or Relying Party) is an entity that uses (consumes, relies on) identity claims. In the above example, the consumer is CloudTrack, which uses the consumed claims to make the authorization decisions..
  • A Security Token is a set of claims securely packaged for transportation between participants. This packaging ensures properties such as
    • Privacy: only the authorized receiver of the token is able to access the contained claims. This typically is obtained by encrypting the token to the authorized receiver.
    • Claim integrity and issuer authentication: the token receiver is able to determine the original claims producer. Usually, this property is achieved by the issuer digitally signing the token.
    • Subject authentication and proof of possession: the token receiver is able to determine who is the subject of the claims. The two more common proof of possession methods are
      • Bearer – any entity who has the token can allege that it is the claims subject. This is similar to bearer checks or bus tickets.
      • Holder of key – the claims subject is any entity who proves possession of a related key (e.g. by signing the message where the token is attached).

TheClaimsModel2

The “Proposal for a Common Identity Framework: A User-Centric Identity Metasystem” contains an interesting taxonomy of claims

  • Claims are divided between primordial and substantive
    • Primordial (or primitive) claims are proofs presentable by only one subject
    • Substantive claims are claims produced by claims providers, typically after the subject presenting a primordial or other substantive claim.
  • Substantive claims are further subdivided in
    • Static – properties of the subject (e.g. National Identifier Number; Date-of-Birth)
    • Derived – derived from other claims (e.g. Portuguese Citizen; Over-18)
    • Membership – role or group membership, relation with other subject (e.g. Administrator; Lead Developer; Purchase Officer)
    • Capability – authorization to something (e.g. Can-emit-purchase-order; Can-admin-CI-server)
    • Contextual – information about the context (e.g. Authentication method, location and time)

Claims transformers

A Claims Transformer is an entity or module that produces claims based on claims that it receives (consumes).

For instance, in above scenario, the WeDev identity provider can also be seen as a claims transformer since it produces the name and role claims (substantive claims) upon receiving and validating Alice’s credentials (primordial claims).

We also can see the CloudTrack’s web app as divided in to two modules:

  • The first module is a claims transformer, transforming the input role claims (LeadDev) into application specific roles (IssueMgr) and authorization roles (IssueView).
  • The second module is an identity consumer, using the input authorization claims (IssueView) to decide if the access is allowed or not.

Notice that the claims exchange between these two modules doesn’t have to use a token, since no unprotected communication channel is used.

In the next post, we will present some of the protocols that are used for requesting and communicating claims and tokens.

Alice in Claims: decentralized identity

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:

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.

TheScenario

Alice accesses the CloudTrack web app

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

  • 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:CentralizedSolution

  • 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. DecentralizedAuthority

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.

Java Memory Model

Some resources about the Java Memory Model:

Exposing a WCF Data Service via the Azure AppFabric Service Bus

 

The How

 

The following excerpt shows how to expose a WCF Data Service via the Azure AppFabric Service Bus, using a self-hosted ServiceHost.

 

using(var host = new DataServiceHost(
                     typeof(PersonsDataService), new Uri[0])){
  host.AddServiceEndpoint(
    typeof (IRequestHandler),
      new WebHttpRelayBinding(
            EndToEndWebHttpSecurityMode.Transport, 
            RelayClientAuthenticationType.None),
      “https://my-namespace.servicebus.windows.net/pds)
    .WithServiceBusTransportCredentials();
 
    host.Open();
    Console.WriteLine("host is opened, press any key to exit");
    Console.ReadKey();
}

where

  • PersonsDataService is the data service to be exposed;
class PersonsDataService : DataService<MyDataModel>{
    public static void InitializeService(
                           IDataServiceConfiguration config) {
    }
}

 

  • IRequestHandler is the WCF Data Services generic service contract (see below);
  • WebHttpRelayBinding is the Azure AppFabric Service Bus binding for the “web programming model”.
  • and WithServiceBusTransportCredentials is an extension method for configuring the service bus transport credentials
public static ServiceEndpoint WithServiceBusTransportCredentials(this ServiceEndpoint edp)        {
    ConfigureTransportCredentials(edp);
    return edp;
}
public static void 
ConfigureTransportCredentials(ServiceEndpoint edp) {
    var tcred = new TransportClientEndpointBehavior();
    tcred.CredentialType = 
            TransportClientCredentialType.SharedSecret;
    tcred.Credentials.SharedSecret.IssuerName = IssuerName;
    tcred.Credentials.SharedSecret.IssuerSecret = SharedSecret;
    edp.Behaviors.Add(tcred);
}

 

 

The Why

WCF Architecture

The Windows Communication Architecture is based on two layers:

  • The Channel Model Layer is a stack of channels that operate on messages, composed by
    • Zero or more protocol channels, implementing protocols such as WS-Security.
    • One transport channel that send or receives the messages from the transport medium (e.g. TCP, pipes). This transport channel uses a message encoder/decoder to translate between the messages handled by the protocol channels and the transport’s byte streams.
  • The Service Model Layer is responsible for the translation between messages and service method calls.

image

 

WCF Data Services

WCF Data Services are layered on top of the WCF Service Model:

image

[ServiceContract]
public interface IRequestHandler {    
    [OperationContract, 
     WebInvoke(UriTemplate = "*", Method = "*")]
    Message ProcessRequestForMessage(Stream messageBody);
}
[AspNetCompatibilityRequirements(
    RequirementsMode = 
        AspNetCompatibilityRequirementsMode.Allowed), 
 ServiceBehavior(
     InstanceContextMode = InstanceContextMode.PerCall)
]
public class DataService<T> : IRequestHandler, IDataService {
    ...
    public Message ProcessRequestForMessage(Stream messageBody){...}
    ...
}

 

Azure AppFabric Service Bus

The Azure AppFabric SDK contains several bindings to expose and consume services via the service bus, namely the WebHttpRelayBinding that uses the Web HTTP programming model. This binding defines a channel stack with a RelayHttpTransportChannelListener that opens a TCP connection to the services bus and listens to messages relayed by it.

image

 

Since the Service Bus bindings extend the channel layer and the WCF Data Services are layered on top of the Service Model Layer, their composition is straightforward.