Monthly Archives: July 2008

What are claims?

The use of classical identity based access control models, on which authorization decisions are based on the requestor unique identifier, is not adequate for large scale decentralized systems, such as the World-Wide Web. Several aspects contribute to this inadequacy, namely:

  • Access control policy -When an access request crosses security domains, the identifier of the requestor on its domains may not have any meaning on the resource’s domain.
  • Privacy – The requester might not want to reveal its unique identifier outside of its security domain

A solution is to base the access control policy on “characteristics” of the requestor that make sense for the authorization decision. The Identity Metasystem extends the notion of identity to incorporate this, proposing the concept of a claims-based identity:

In the Metasystem, digital identities consist of sets of claims made about the subject of the identity, where “claims” are pieces of information about the subject that the issuer asserts are valid. This parallels identities used in the real world. For example, the claims on a driver’s license might include the issuing state, the driver’s license number, name, address, sex, birth date, organ donor status, signature, and photograph, the types of vehicles the subject is eligible to drive, and restrictions on driving rights

Unfortunately, there isn’t a formal definition of claim. Instead there are several several more or less vague definitions:

One way to better understand the claims concept and its applications is to see how:

  • Claims are communicated and attached to requests and messages, using security tokens.
  • Claims are required by services and applications, using policies.
  • Claims are used in authorization decisions.

This will be the subject of future posts.

Privacy as an Human Right

Via Light Blue Touch Paper:


The European Court of Human Rights said in a judgment on Thursday that Finland had failed to protect the confidentiality of patient information and ordered the state to pay a nurse about 14,000 euros in damages and 20,000 euros in costs.


The Strasbourg court found unanimously that the district health authority, by failing to establish a system from which the nurse´s confidential patient information could not be accessed by staff who did not treat her, had violated article 8 of the European Convention of Human Rights [emphasis added], which says “everyone has the right to respect for his private and family life, his home and his correspondence”


Zermatt” is name name of a municipality in Switzerland.

Is is also the code name of a Microsoft framework for implementing claims-based identity. There is a nice white paper describing it, authored by Keith Brown.

Currently, “Zermatt” is composed by a managed assembly (Microsoft.IdentityModel.dll) that includes:

  • A set of classes implementing a new model for claims, claims-based identities and claims-based principals.
  • The infrastructure necessary to use the above model on relying parties, namely:
    • WCF-based services
    • ASP.NET based web applications.
  • A framework for the construction of security token services, supporting both the active (WS-Trust) and passive (WS-Federation) profiles.
  • A set of classes for handling information cards.
  • A set of ASP.NET controls for signing-in based on information cards or on a “passive” federation.

The package also contains a very interesting set of samples.

WCF and the AsyncPattern property (part 3)

This is the third in a series of posts about the AsyncPattern in WCF.

The previous two posts described the purpose and usage of this property on the service side. The present post addresses the client side.

AsyncPattern at the client side

The AsyncPattern=true is used at the client side to expose an asynchronous programmatic interface to a service operation. Similarly to what happens at the service side, this property defines the local communication pattern between the service’s client code and the WCF runtime (at the client side).

Consider the following WSDL excerpt defining a portType with two request-response operations

   1: <wsdl:portType name="IService">
   3:   <wsdl:operation name="Operation1">
   4:     <wsdl:input wsaw:Action="..." message="..." /> 
   5:     <wsdl:output wsaw:Action="..." message="..." /> 
   6:   </wsdl:operation>
   8:   <wsdl:operation name="Operation2">
   9:     <wsdl:input wsaw:Action="..." message="..." /> 
  10:     <wsdl:output wsaw:Action="..." message="..." /> 
  11:   </wsdl:operation>
  13: </wsdl:portType>

By default, the interface generated by svcutil.exe has a synchronous interface

   1: public interface IService {
   3:     [System.ServiceModel.OperationContractAttribute(Action=".../Operation1", ReplyAction=".../Operation1Response")]
   4:     ReplyData Operation1(RequestData rd);
   6:     [System.ServiceModel.OperationContractAttribute(Action="", ReplyAction="")]
   7:     ReplyData Operation2(RequestData rd);
   9: }

However, using the /async switch, the svcutil.exe can also generate an interface with synchronous and asynchronous methods.

   1: public interface IService {
   3:     // Operation 1 synchronous method   
   4:     [System.ServiceModel.OperationContractAttribute(Action=".../Operation1", ReplyAction=".../Operation1Response")]
   5:     ReplyData Operation1(RequestData rd);
   7:     // Operation 1 asynchronous method pair         
   8:     [System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action=".../Operation1", ReplyAction=".../Operation1Response")]
   9:     System.IAsyncResult BeginOperation1(RequestData rd, System.AsyncCallback callback, object asyncState);        
  10:     ReplyData EndOperation1(System.IAsyncResult result);
  12:     // Operation 2 synchronous method   
  13:     [System.ServiceModel.OperationContractAttribute(Action=".../Operation2", ReplyAction=".../Operation2Response")]
  14:     ReplyData Operation2(AsyncPattern.Client.AsyncClient.RequestData rd);
  16:     // Operation 2 asynchronous method pair         
  17:     [System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action=".../Operation2", ReplyAction=".../Operation2Response")]
  18:     System.IAsyncResult BeginOperation2(RequestData rd, System.AsyncCallback callback, object asyncState);        
  19:     ReplyData EndOperation2(System.IAsyncResult result);
  21: }

Note that:

  • This setting does not change the communication pattern between the client and the service.
  • Using AsyncPattern=true at the client side is not in any way related to using AsyncPattern=true at the service side (the service doesn’t even have to implemented over WCF!)

AsyncPattern=true versus BeginInvoke

As stated here, using the delegate’s BeginInvoke method is not a way to achieve the same effect as AsyncPattern=true.


  • If the delegate target is a client channel instance (returned by a ChannelFactory), then the call will block (as described in a previous post).


  • If the delegate target is a “client proxy” (ClientBase derived class generated by svcutil.exe), then the call will not block. However a thread will remain blocked until the reply is received (the thread from the thread pool used to call the asynchronous method). This does not happens when using AsyncPattern=true, since the WCF supports full asynchronous requests.
    The blocking of this thread may not be significant on a smart client scenario. However, this “thread consumption” may be problematic on a middle-tier scenario, where a significant amount of requests may be pending at a given moment in time.