Windows Azure - AppFabric Access Control Service -
Introduction
In this article we can explore the Access
Control service of Windows Azure AppFabric. As you know the
services provided by AppFabric are shown below.
Theory
on Access Control
The Access Control Service (ACS)
provides a flexible way of authentication and authorization in the cloud
premises. The ACS extracts out the authentication and
authorization code outside the application.
We can use ACS along with:
- Web Applications
- Web Services
Simply, the Access Control
Service 2.0 allows us to integrate single sign on (SSO) and centralized
authorization into the web applications.
In the old
applications we need to incorporate the authentication and authorization code
inside our applications. This will lead to mixing of business
logic with the security overheads. The PrincipalPermission
attribute, Cookie Presence Checking etc. are some of the ways of doing
it. AppFabric through ACS provides a better way of dealing with
security aspects.
Protocols: The
following protocols are supported by ACS 2.0
- WS-Trust
- WS-Federation
- OAuth
Identity Providers:
The identity providers supported by ACS include:
- Windows Live ID
- Facebook
- Google
- Yahoo
- WS-Federation Identity
Providers
Compatibility: ACS
is compatible with web platforms including:
- .Net
- PHP
- Java
- Ruby
- Python
Difference between Old
Application and Azure Application Security Aspects
Service
Namespace: Like the Service Bus, we need to
create a service namespace for the Access Control Service too. The
services in a particular namespace share the same DNS name. The
Service Namespace acts as a top level partition around the end points.
There are different endpoints inside the
namespace:
- Security Token Service
- Management Service
- Management Portal
- Service Metadata
The format of the end point
will
be:
https://.accesscontrol.windows.net/mgmt
Managed
Namespace: A managed namespace is partially managed by another
service. The Service Bus and Cache services uses managed
namespaces characterized by –sb and –cache
respectively.
Relying Party: In the
context of ACS, relying party is an application for which we are implementing
federated authentication. The configuration includes a term Realm
which acts as the URI. There is a Return Url which is invoked to
provide the token when the invoker is valid.
Example of Realm are: http://contesso.com. Any request
with Realm prefix with http://contesso.com
will be gaining valid tokens. We can also include http://localhost/ as a valid
realm.
We can also configure an Error url which will be
invoked during any problems in the login process. Eg:
http://www.yourdomain/error.htm
The configuration of relying
party application can be manual or through program. The relying
party control flow is depicted below.
Rule
Groups: A relying party application should be associated with
at least one rule group. If the Real match one configured
application which is not associated with any of the rule groups, the token will
not be issued.
We can associate one rule group with more
than one application and one application with more than one rule
group.
Summary
In this article we
have learnt about the AppFabric Access Control Service. It
provides a better way of authentication and authorization. In the
next article we can see how to create a service namespace and using the Access
Control Service Portal.