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:
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://<servicenamespace>.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.