Windows Azure - Introduction of AppFabric Access Control Service

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