Code me up, code me down

Security Token Service by Gudge

2006-06-20T01:06:00Z

Martin Gudgin has posted a sample STS implementation on top of WCF, which is available here. I used a stripped down version of this STS during my TechEd talk.

WCF Custom Security Tokens

2006-06-16T15:16:00Z

I had another TechEd chalk talk on Friday 6/16 at 10:45am, this time around creating custom security tokens in WCF. The interest was much lower than in claim based authorization infrastructure I presented on Wednesday. Does SAML satisfy all security token needs?

During the talk I presented a sample implementation of a username/key token. The code can be obtained here. The idea behind the username/key token is to use a public/private key pair instead of a password. The caller authenticates with the service by signing the message with the private key associated with his token. The service authenticates the caller by validating the signature and ensuring the username presented in the token is associated with the public key used to verify the signature.

The talk demonstrated the use of key extensibility points in the WCF security infrastructure:

SecurityCredentialsManager. This class encapsulates authentication, token provisioning, and serialization settings controlling all of the token infrastruucture in WCF. Typically this is used to expose a usable set of properties to set credentials and authentication settings in the system. WCF ships with the client side and service side implementation (ClientCredentials and ServiceCredentials, respectively), which can be derived from to address the needs of a custom security token. SecurityCredentialsManager acts as a factory of SecurityTokenManager.

SecurityTokenManager. This class encapsulates the three major aspects of security token processing at runtime: serialization, authentication, and provisioning. SecurityTokenManager acts as a factory of SecurityTokenProvider, SecurityTokenAuthenticator, and SecurityTokenSerializer. Token providers and authenticators are created given SecurityTokenRequirements which describes the properties of the tokens to be proffered of authenticated, respectively. Token serializers are created given a set of specifications which describe the desired serialization formats.

SecurityTokenProvider. This class is responsible for creating SecurityTokens at runtime. It encapsulates the caching semantics, instancing behavior, and abstracts away protocols used to obtain the security tokens, if any. For example, WCF implements SSPI negoatiation, SSL/TLS negoatiation, and WS-Trust exchange with a SecurityTokenService as a SecurityTokenProvider.

SecurityTokenAuthenticator. This class is responsible for validating a security token when it is received from the remote party and unifying the representation of the token in the form of IAuthorizationPolicy. IAuthorizationPolicy is part of the claim-based authorization model introfuced in WCF which I covered in the Wednesday's chalk talk. For example, a token authenticator responsible for authenticating an X.509 secuurity token could validate the trust chain of the certificate before creating an IAuthorizationPolicy encapsulating the the DNS name, common name, public key, etc. from the X.509 certificate.

SecurityTokenSerializer. This class is responsible for serialization and deserialization of security tokens and security key clauses. Keeping this functionality separate from the SecurityToken implementation allows for a 1:n relationship between the token and its serialized form, therefore easing the development effort required to satisfy alternative serialization formats.

SecurityToken. This class represents an abstraction of a credential which allows the WCF system to generically process credentials of different types. Security token may have zero or more cryptographic keys associated with it, which can be used to offer authentication, integrity, and confidentiality of message exchange.

SecurityTokenParameters. This class represents a description of security token type and properties necessary to configure a security binding in WCF. It is also directly related to the concept of a security token assertion from WS-SecurityPolicy 1.1. SecurityTokenParameters acts as a factory of SecurityTokenRequirements, providing a bridge between System.ServiceModel and System.IdentityModel namespaces.

SecurityTokenRequirements. This class from System.IdentityModel is a conceptual equivalent of SecurityTokenParameters from System.ServiceModel. It specifies the properties of a security token and act as input to the factory methods on SecurityTokenManager.

SecurityKeyIdentifierClause. This class represents the concept of a token reference. When the recipient of the message already has a copy of the security token that is used to secure it, a token reference may be used to uniquely identity the token as opposed to including the token in the message. Token references have typically more compact serialized form than token themselves, which provides performance benefits. For example, instead of including the service's X.509 token in the request message, the caller can include a reference constsing of a thumbprint of the X.509 certificate, which uniquely identifies the token on the service side.

WCF Service Authorization with Claims

2006-06-15T16:26:00Z

During my TechEd chalk talk on Wednesday 6/14 at 8:30am I walked through the process of claim-based service authorization in WCF. Despite the early hour combined with the richness of Boston's night life (at least relative to Seattle) a number of attendees showed up, which was a pleasant surprise.

A few people asked for the sample code I was using to demonstrate the concepts, so I am posting it here. The project contains a sample Security Token Service implementation, but by no means is it complete or works correctly outside the scope of the features demonstrated by the sample project. Nevertheless, it may provide a useful starting point to implement your own. The slides are available here.

Claim-based authorization is a new model of authorization introduced in Windows Communication Foundation. It is more generic and addresses more scenarios that the CLR authorization model (IIdentity, IPrincipal). While the CLR authorization model addresses role-based access control scenarios well and integrates smoothly with windows accounts, it has a number of disadvantages when used for controlling access to web services. First, there is no configuration support that allows access check to be added to an existing service. The developer has to express the constraints decalratively in code using the PrinciaplPermissionAttribute or imperatively within the service method using PrincipalPermission class. Second, the representation of caller's identity is limited to a simple string, which is insufficient in the world of heterogenous credential types used for authentication in the web service space (e.g. X.509 certificates, SAML assertions). Third, the concept of roles is part of the model, which excludes more complex scenarios for expressing access control decisions. Claim based authorization framework attempts to address these limitations by providing a more generic model capable of addressing heterogenous credential types, the ability to specify authorization policies through configuration at deployment time, and the flexibility to express arbitrary access control decisions based on the available evidence.

The claim based authorization framework can be used outside of WCF in a very generic manner. Below I will try to introduce some of its concepts as they relate to web service authorization in WCF:

Claim. A claim is an atomic statement made in the context representing the web service caller. It is defined by a triplet (type, right, resource). An example of a claim is a name claim (“name“, “possess property“, “tjanczuk“), which indicates the subject has a property of type name with value “tjanczuk“. Such a statement can be used to represent the username of a web service caller. You can imagine similar claims with specific claim types can be created to represent other concepts, e.g. public keys, SIDs, DNS names, e-mail addresses, or roles.

ClaimSet. A claim set is an enumeration of claims with a common issuer. For example, a claim set based on an X.509 certificate can contain a number of claims representing the statements made by the certificate (common name, DNS name, e-mail address, public key, thumbprint, etc.), while the issuer of the claim set maps to the issuer of the X.509 certificate. The abstraction used to represent the claim set's issuer is a ClaimSet itself, which makes sense considering the issuer of an X.509 certificate is another X.509 certificate.

IAuthorizationPolicy. Authorization policy is an extensibility point which allows new claim sets to be added to the context representing the web service caller. In WCF, authorization policies come from two sources. First, they are created based on the security tokens supplied by the caller in the request. The goal of these authorization policies is to unify the representation of heterogenous security token types (e.g. X.509, username/password, Kerberos, SAML) by extracting the evidence found in a given security token and representing it as a ClaimSet which can be later processed generically regardless of what the initial credential type was. The second type of authorization policies is configured by the administrator of the system with the goal of adding additional claim to the authorization context associated with the call based on local security policy. A typical example would be an authorization policy which uses a local database that maps users to roles to add a new claim set representing the roles associated with the current caller.

ServiceAuthorizationManager. Service authorization manager is a gatekeeper that makes the final access control decision to either grant or deny the caller access to a service. Service authorization manager is called for each request to the service. Typically, ServiceAuthorizationManager would determine the necessary requirements the caller must meet based on the provided operation context (for example, a method the caller is trying to invoke), then inspect the available evidence about the caller in the AuthorizationContext and make a final yes/no decision. AuthorizationContext contans all the claim sets resulting from applying internal and external authorization policies. For example, at this point the AuthorizationContext can contain a claim set with claims representing the roles the caller is in, as well as other claim sets describing credential-type specific attributes of the caller (e-mail, username, DNS name, public key, etc).

Claim-based authorization model is not replacing the CLR authorization model. It provides an alternative that may or may not be more adequate in a given scenario. In particular, WCF also integrates well with CLR authorization by allowing the Thread.CurrentPrinciapal be populated for each call based on the AuthorizationContext representing the caller. This allows CLR authorization model to be used directly in WCF services.