Windows Azure Platform
AppFabric Access Control Overview
AppFabric Access
Control represents the Windows Azure implementation of the “claims-based
access control, as-a-service” concept previously discussed. It is a
cloud-based security and access control management service that
leverages federated, claims-based identities and a declarative rules
model in order to abstract the complexities of cross-domain
authorization and interoperability (Figure 1). Access Control provides the default security layer for
Service Bus, but it can also be used to protect any service
implementation (on-premise or cloud-based).
The Identity Metasystem
model, is the foundational
architecture implemented by Access Control. Access Control exists as the
cloud-based service that manages the trust relationships, credentials,
identities, roles, and privileges, and also acts as an STS that issues
claims and handles claims transformations to enable the use of
claims-based identity in enforcing secured access to services.
Unlike traditional
claims-based service authorizations, Access Control has a Secure Token
Service already integrated into the Service Bus and can be leveraged
seamlessly to support cloud-based service authorizations using federated
identities without requiring service consumers to implement any part of
it.
When a service
consumer attempts to connect to a service endpoint on a Service Bus that
is protected by the Access Control service, the consumer logic will
need to authenticate itself with the Service Bus. The authentication
request comes in the form of a security token that is issued by Access
Control in order to authenticate the client and subsequently authorize
access to the resource (the service).
This same mechanism is
enforced on the service end as well, when a service implementation
attempts to attach to and listen on a rendezvous address on Service Bus.
Specifically, services need to obtain a token issued by Access Control,
which contains a claim stating the listen privilege on the requested
service. Service consumers, on the other hand, need to obtain a token
that contains the send claim. Consumer programs can obtain these tokens
from Access Control by supplying credentials that have been granted
permissions to access the targeted service endpoints.
Access Control supports
several different types of credentials, including:
The programming model supported
by the WCF-based AppFabric SDK abstracts the complexities in working
with various identity frameworks and interacting with the corresponding
service implementations. The WCF relay bindings transparently handle the
credentials exchange, token acquisition, and token submission for
establishing access to service endpoints.
There are three basic components of Access Control:
You can use the portal to manage the Access
Control namespace and the entities within it. The management Web service
provides a REST API that can also be used to interact with Access
Control.
Note
Access Control supports
an industry standard protocol called Open Authentication Web Resource
Access Protocol, or OAuth WRAP. To learn more about this standard, visit
www.soaspecs.com.
Access Control
Step-by-Step
Let’s now look at the
mechanics of Access Control by stepping through the interaction of a
service and a service consumer that communicate and exchange claims via
Access Control components. Figure 2 illustrates the scenario that is further described in the
following step-by-step descriptions.
The numbers in the
following list correspond to the step numbers in Figure 2:
1. | The
listening service and Access Control need to establish a trust
relationship with each other by exchanging a 32-byte symmetric key that
is refreshed periodically. Then, the service and Access Control
negotiate how each will encrypt the claim tokens. To accomplish this,
they exchange certificates that contain their public keys. The service
sends its public key certificate to Access Control so that it can
decrypt the claim tokens from the service. Similarly, Access Control
sends its certificate to the service so that the service may operate on any
encrypted tokens it receives from Access Control or directly from
requesting consumers. This key exchange is the primary mechanism that
the service uses to ensure the integrity of the tokens it receives. This
key can be rotated as deemed necessary by the service’s security
requirements.
|
2. | Next,
access control rules are defined for a service consumer. When you create
an Access Control account, you are essentially given a piece of the
Access Control service. This piece is called a service
namespace. These rules will control the types of claims that you
want Access Control to accept on your behalf (such as the input
claims), as well as the claims that you want Access Control to send to
the listening service (such as the output claims).
|
3. | At this point, we have configured Access Control and
performed the necessary bootstrapping before processing consumer
requests. Now, when a service consumer requests the service’s public URI
that is hosted by the AppFabric Service Bus, it will be authenticated
against Access Control (specifically, it will be authenticated against
the Access Control service namespace). The consumer request includes an
access token that contains a set of claims. These claims live in the
Authorization header of the HTTP(S) request message.
Note
Access Control
provides three mechanisms for requesting an access token:
The service consumer
can send a request in plaintext over an HTTPS/SSL channel. This method
doesn’t require any message encryption or crypto exchange, making it a
relatively simple option. A token that has been signed by an approved delegate is
provided using an HMAC SHA 256-bit signature. The approved delegate is
most likely going to be an already approved STS. The Windows LiveID
(WLID) STS provider is a common, well-established example. In this case,
a consumer would have already authenticated itself with the WLID STS
and received an encrypted token. It then uses this token when requesting
an access token with Access Control, which it then sends to Access
Control. Another
option is to request access tokens by leveraging ADFS (specifically, an
issued SAML bearer token). With this approach, the service consumer has
authenticated itself using its Active Directory domain credentials and,
in turn, receives the bearer token from ADFS. The consumer can then use
that bearer token in the request.
|
4. | This is where the
authorization process begins. The token request input claims are
validated against a set of rules whereby the output of these rules
either grant or deny the requesting consumer access to the target
resource (the service). If request is granted, Access Control returns a
Simple Web Token back to the consumer and signs it with an HMAC key that
it shares with the service.
|
5. | Now that the service consumer has successfully
authenticated its identity and Access Control has returned an SWT with
the right set of output claims, the consumer can use that token when
communicating with the protected service.
|
6. | The service runs its own validation rules that drive
how it behaves with the service consumer.
|
Note that it is common
to prefer an asymmetric key exchange model over the use of a shared key.
Since Access Control shares the signing key with the protected service
(because the service may want to validate the tokens that it receives
from the consumer), there is nothing preventing the service from
creating and signing tokens in the same fashion. This means that we
(from a consumer perspective) could not tell the difference between a
token signed by Access Control and another signed by the protected
service. Preventing such scenarios is also known as non-repudiation,
which states that a signature should tell us the origin of the data.
As long as we understand this
and plan accordingly, it should be possible to continue using shared
keys. For example, we don’t want to share keys between protected
resources. Suppose an attacker compromises one of our services and
obtains the signature used to sign tokens. If the compromised service
shared its key with another service, then the attacker could start
attacking that other service. By giving each resource its own unique
signature, we can minimize the damage from potential security breaches.
Access Control and REST
Access Control can be used to
protect REST-based service endpoints and support interactions between
REST services and REST service consumers. It also provides REST-based
APIs for establishing and managing the configurations and relationships
implemented in Access Control.
The interaction model for
REST-based services is exactly the same as for services built with the
AppFabric SDK. The service consumer first uses the OAuth WRAP protocol
to request Access Control for access tokens (or claims) to a targeted
REST service endpoint. Access Control then verifies the credentials
contained in the WRAP request against the pre-configured rules and
identity mappings. If the presented information has access privileges,
then a set of claims are generated by Access Control, packaged into a
token, and returned to the consumer program. The tokens are generated
using the SWT format and signed with HMAC SHA 256 encryption.
The service consumer then
just needs to include the token in the HTTP Authorization header and
send it along with the request message to the targeted REST service
endpoint. The token may be reused by the consumer until it expires. The
REST service implementation can then verify the token by successfully
decrypting the contained claims (which may have been transformed by
Access Control based on the configured claims transformation and mapping
rules), and use that information for processing.
Access Control exposes
these token-exchange endpoints for REST service consumers as follows:
plaintext –
no cryptography required
signed token – uses a
symmetric key and enables simple delegation via the SWT token format
SAML bearer token – enables federated identities with
identity providers (such as ADFS v2)
Access Control Service
Authorization Scenarios
Access Control supports a
diverse set of distributed service authorization scenarios, which can be
represented by three high-level authorization models. These models can
be used to support commonly used service composition and interaction
patterns, regardless of the actual location of participating services.
Hybrid Cloud
Authorization Model
This model generally
includes services across on-premise (internal) and public (external)
cloud environments and a single identity provider; however, claims
mapping and transformation processing is typically not required.
This model is commonly
used for the following scenarios:
enterprise single
sign-on– Access Control can
leverage identity federation (such as ADFS v2) to enable an organization
to reuse its own identities to access cloud-based services.
extranet access– Access
Control can be used to grant access to external consumers in other
identity domains to gain access to on-premise services (and in some
cases reverse-mapping claims into directory identities to grant access
to legacy systems that are not claims-aware).
dedicated, single-tenant SaaS– Similar to enterprise single sign-on, except
the cloud-based services are managed by an external organization and
considered part of an enterprise’s internal environment.
Public Cloud
Authorization Model
This model represents the
use of public cloud-based services together with multiple identity
providers. In this case, claims mapping and transformation processing is
typically required.
This model is commonly
used for the following scenarios:
consumer service– Access Control can support identity
federation with online digital identity providers (such as Windows Live
ID), so that the cloud-based service does not have to implement its own
identity management system.
multi-tenant SaaS–
Similar to consumer service, Access Control can support a cloud-based
service to provision access to multiple customer organizations using
their own identity management systems via federation.
Cloud-to-Cloud
Authorization Model
With this model, services
reside in private clouds although cloud-to-cloud interaction with public
cloud scenarios may also be supported. Multiple identity providers are
involved and claims mapping and transformation processing is also
required.
This model is commonly used for the following
scenarios:
multi-enterprise
integration– Access Control can be
used to bridge different security domains in separate organizations and
transform claims to the format recognized by the relying party.
B2B integration– Essentially the same scenario as
multi-enterprise integration, except security domain trust levels can
vary.
