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:
- Identity Metasystem: “claims are pieces of information about the subject that the issuer asserts are valid“
- WS-Federation: “A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege, capability, attribute, etc).“
- Understanding Windows CardSpace: A claim represents a fact about something or somebody. Better. A claim is a statement that a certain fact applies to something or somebody. As such, it is subject to verification. In other words, you can accept or reject the claim based on your beliefs, knowledge of the situation, and so on.
- Cambridge dictionaries online: “a statement that something is true or is a fact, although other people might not believe it”
- MSN Encarta: “something that may be true: an assertion that something is true, unsupported by evidence or proof“
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.
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.
This is the third in a series of posts about the AsyncPattern in WCF.
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
By default, the interface generated by svcutil.exe has a synchronous interface
However, using the /async switch, the svcutil.exe can also generate an interface with synchronous and asynchronous methods.
- 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
- 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.