Before we can begin using the Windows Azure AppFabric Access Control Service (ACS) to decouple our applications from security concerns and enable claims-based identities we need to understand the Resources contained in the Service Namespace and what role they play in the authentication and authorization infrastructure. This brief blog entry is meant to provide you with the basic understanding and vocabulary required to get started.
The Service Namespace is an abstraction for the collection of ACS Resources including Token Policies, Scopes, Issuers, and Rules (which are described in more detail below).
The Service Namespace is comprised of a hierarchy of related entities. At the root of this hierarchy is the AppFabric Service Account Project. The Service Namespace can be broken into three constituent parts as shown in Figure 1, the Token Policy, the Scope, and the Issuer.
Figure 1 – Service Namespace Object Hierarchy
A Token Policy defines token expiration periods and digital signing keys. A Token Policy may be shared across Service Namespaces and is used by the ACS to sign the response tokens and to set their expiration periods.
An issuer is a party that will issue requests for tokens from the ACS. An Issuer may not be shared across Service Namespaces.
A Scope groups rules governing ACS token issuing behavior. A Scope contains exactly one internal RuleSet object which can be populated with multiple Rules. A Scope may not be shared across Service Namespaces.
A Rule defines a transformation between one or more input claims and one or more output claims. Rules cannot be shared across Service Namespaces. The Rule feature is one of the most powerful and innovative features of the Windows Azure ACS.
A RuleSet is a collection of individual Rule objects. We do not directly create the RuleSet object; one is created automatically for us as part of a Scope.
The ACS Rules engine uses Rule objects to perform actions using incoming claims to create outgoing claims. A Claim is a statement that can be made about an entity. Applications and Services such as the ones that you will build specify what claims are necessary to perform a given operation.
Simply stated, an Identity is a collection of claims. Your ACS enabled application will accept identities from the ACS, an identity provider that your application implicitly trusts. The ACS will verify the claims made by your application users, and will transform those claims into ones usable by your application using the Rules defined in the Ruleset of the Scope that applies to your Service Namespace.