Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Azure

Authentication and Authorization with WCF (part 3) - Claims-Based Authorization

3/20/2011 3:53:09 PM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

Claims-Based Authorization

It is generally agreed by many that roles are sufficient for simple cases where the services do not need to provide fine-grained access control over resource and operations. Claims-Based Authorization [MPP] goes a step beyond the use of roles to govern resource access. Many times roles do not provide enough precision to enable the control that you might need for a given service. Claims, however, are able to represent many characteristics needed for different security scenarios, including identity, roles, rights, and other attributes of the consumer that might be of interest to the service.

In Plain English

A claim can be literally anything that describes aspects of a subject, be it an actual person or an abstract resource. A claim is endorsed by an authority; which means one observer can decide if the fact the claim represents should be considered true according to the authority’s trustworthiness.

For example, the passports we use as a form of identification when traveling outside of our resident countries can be considered as a form of claims-based identity. The passport document represents a token (typically issued and signed by authoritative government agencies), which contains information (or specifically, claims) such as ID number, name, birth date, and other aspects that are associated with an individual.

The passport allows us to enter other countries (security domains) because of an existing trust relationship. The process of supplying credentials to prove or verify our identity only needs to be done once with the passport-issuing agency (as with a Security Token Service). We no longer need to re-authenticate again once we have a valid passport; we just need to present it as a form of trusted token.

A claim represents a right with respect to a particular value. The right can be considered an action, such as read and write, or it can posses a value that can be viewed as some system resource, such as a database, a file, or an operation. Claims are governed by claim type, which is a value representing a category of claims. For example, a service consumer could present a claim of type file with a read right over a value of “resume.doc.” This translates to a read permission to the file “resume.doc.”

Claims are generic enough to enable rights to be exercised over many different types of objects. For example, an internal consumer of a service might possess a Windows credential as proof of identity, whereas an external consumer accessing the same service may not have a Windows credential that can be validated by the service. The service may therefore require X.509 certificates for these consumers. In either case, the consumers can assert their identities using claims.

WCF generates claims from security tokens. Security tokens are abstractions of credentials validated by the security policy of the service that populates the security headers of an incoming message. Once the security token is validated, the claims are extracted and placed in the security context of the current operation. The resultant set of claims is known as a claim set. A claim set is a collection of claims provided by a common issuer and exists for each set of credentials being authenticated.

The authorization manager allows claim sets to be added to the security context of a request. Claim sets can be created from the security token passed to the service in the message. The goal of the claims created in this manner is to provide a unified mechanism for evaluating the information found in many disparate types of security tokens. The framework extracts the evidence found in these security tokens and represents it as a claim set.

Claim sets can also be added to context administratively. This feature allows additional claims to be added to the security context allowing the local security policy to be represented in the claim set.

The service authorization manager makes the final decision to grant or deny the calling consumer program access to the service’s resources. The role of the service authorization manager is to determine the access requirements of the resource in question and inspect the evidence presented by the consumer to determine whether it meets those requirements. The decision is made to grant or deny access based on this evaluation.

Claims Processing in WCF

Claims are a first class citizen of WCF and are represented by the Claim type. A claim represents an assertion by a consumer that it has a right to the requested resource. That resource might be possession of an identity or permission, such as read access to a database. Claims can be constructed at runtime by creating an instance of the Claim class and setting its Type, Resource and Right properties, as follows:

Example 7.
Claim emailClaim = new Claim
"[email protected]",

As mentioned previously, a claim set represents a collection of claims issued by the same source. A claim set extracted from a CardSpace token would be placed in the security context with the CardSpace provider identified as the issuer. The Issuer member of ClaimSet is another ClaimSet that represents the issuer of the consumer program’s claims.

ClaimSet is an abstract class, meaning you cannot explicitly create an instance of ClaimSet. Instead, you must use the DefaultClaimSet type or create a new type derived from ClaimSet and create an instance of that instead. It is important to note that once the claim set is created, it cannot be changed.

The WCF service model processes the security tokens provided in the message and creates claim sets based on the type of token being processed. The generated claims are placed in the security context and become accessible at runtime through the AuthorizationContext.

AuthorizationContext contains a quantity of ClaimSet equal to the number of security tokens in the request and the number of authorization policies associated with the service.

Accessing claims from the authorization context is quite straightforward as shown here:

Example 8.
AuthorizationContext context =
foreach(ClaimSet claims in context.ClaimSets)
WindowsClaimSet windowsClaims;
if(claims.GetType() == typeof(WindowsClaimSet))
windowsClaims = (WindowsClaimSet)claims;
if(windowsClaims.ContainsClaim(new Claim
"[email protected]",
Rights.PossessProperty)) == false)
throw new Exception("It's not who we want it to be!");

Implementing Claims-Based Authorization

The value of a claims-based model is its ability to represent consumer assertions in a consistent manner, regardless of the source of the assertion. Most services need to support consumers regardless of domain or platform affiliation. Authorizing resource access can prove exceptionally difficult without a means to normalize consumer credentials and security demands. Rather than restrict the service to a limited use model (such as roles), we can design a claims-based system that enables us to build a flexible authorization mechanism that is not bound to a specific credential type or collection of roles.

In this way the service can meet the authorization requirements of the consumer designers without affecting business requirements tied to consumer identities (Figure 3).

Figure 3. The claims-based WCF service model normalizes claims of different types in order to evaluate them in an identical manner.

Access Control in Windows Azure

With Windows Azure services, authorization implementations and integrations can be externalized from the service logic and managed as a set of declarative rules through the use of Access Control. Windows Azure Access Control supports claims-based authorizations in federated identity scenarios, enabling single sign-on across separate security domains.

For example, organizations that leverage Active Directory Federation Services (explained shortly in the Windows Identity Foundation (WIF) section) can enable users/consumers to authenticate and sign on to external cloud-based services using the organization’s identities.

Access Control features include:

  • claims transformation engine using declarative rules and policies

  • security token service (STS)

  • support for multiple credentials, including Windows Live IDs, SAML tokens, and X.509 certificates

  • setup Issuer trust with a simple Web interface or programmatically through APIs

  • support for Active Directory and other identity infrastructures

Designing Custom Claims

As is the case with any architectural approach to security, the first step is to determine which resources need to be protected and the requirements necessary to access those resources. The result of this activity becomes the basis of custom claims designed for the service.

Often times, a resource-centric security model is the most straightforward approach to take. The goal of service security is to protect the resources under the care of the service implementation. Resources can be data (such as a business entity) or a physical resource (such as a report). Consumer rights can be established by defining a specific set of actions that can be performed on those resources.

Other -----------------
- Connecting in the cloud with AppFabric : Listening for messages on the bus
- Connecting in the cloud with AppFabric : Connecting with the Service Bus
- Example: A return to our string-reversing service (part 4) - Configuring the ACS namespace
- Example: A return to our string-reversing service (part 3) - Sending a token as a client & Attaching the token
- Example: A return to our string-reversing service (part 2) - Accepting tokens from ACS & Checking the token
- Example: A return to our string-reversing service (part 1) - Putting ACS in place & Reviewing the string-reversal service
- Connecting in the cloud with AppFabric : Controlling access with ACS
- Joining dynamic and infrequently changing data together
- Enterprise Service Bus with BizTalk Server and Windows Azure : Mapping the Microsoft Platform to the Enterprise Service Bus Pattern
- Enterprise Service Bus with BizTalk Server and Windows Azure : Governance Considerations
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Windows Vista
Windows 7
Windows Azure
Windows Server