Securing WCF Services exposed on Azure Service Bus Namespace - Part 1

Tweet

Security is one of a main requirement that expected from most of our application which is targeting to a particular group of users whether it is a Web Application or a Service. In previous days, authentication and authorization was handled by application itself by creating user accounts in the application and implementing role for each user which makes difficult to the user to remember lots of things such as user name, password and the application support team to maintain the application.

Windows Azure Access Control Server is a cloud based service that provides an easy way to achieve the authentication and authorization functionalities for any applications or sevices by simple way. As the ACS implementation can be separated from the application logic, it will be easy to maintain either application or authentication module without changes in others.

ACS provides lots of features, such as integration with WIF, lots of external identity provides such as Windows Live ID, Google, Yahoo and Facebook. So any application which is targeting to the public user can implement any of the external identity providers and use their profile created from external system itself. The applications which are targeting to the enterprise users can use the enterprise Active Directory credentials by using ADFS support.

It also supports various protocols such as OAuth 2.0, WS-Trust, and WS-Federation and various token formats such as JSON Web Token (JWT), SAML 1.1, SAML 2.0, and Simple Web Token (SWT).

For more information about ACS, please refer the following url –
http://msdn.microsoft.com/en-us/library/gg429788.aspx
http://msdn.microsoft.com/en-us/library/gg429786.aspx

Authentication and Authorization process with ACS
When an application or a service registered with ACS service, there will be multiple steps happening while authentication and authorization process involved.

Below diagram shows the steps involved while accessing a service which has been configured with ACS.

(Note: The diagram is taken from channel 9 vedio - Securing Service Bus with ACS. I explained below steps which I got from the same vedio – any errors pls comment.)

1. The first step the client needs to do before calling Access Control Service is get the Identity token.
   
   There are two ways to get the identity token -
   
   • Passive Model - When the client configured authentication using a third party identity providers such as Live Id, Google Id, Yahoo Id or Facebook, the application first redirects the user to the specified identity provider login page. The user submits their credentials to the Identity Provider UI (For Ex: Face book Login Page). On successful login, the identity provider redirected back to the client with Identity Token.
     Note: To login to the IP, the user required to Sign Up in those applications)
   • Active Model - The client goes to the STS provider such as ADFS, Custom STS provider etc. which is own by the application owner (enterprise). Once the Authentication successful, it returns Identity Token to the client.
2. Once the Identity provider authenticated successfully, it returns an Identity Token when redirecting back to the client. The Identity Token contains information about the user who logged into the system successfully such as who is the User, what is the Mail Id and some additional information based on the Identity provider. This Token will be digitally signed by Identity Provider.
3. The client then request Access Control Service with the Identity Token and the Realm (a Service URI) that need to get the access. The Access Control Service checks the Realm registered and the Identity Token which comes from the known and trusted Identity Providers.
4. If the ACS knows the Realm is registered with the Relying Party Application and Identity Token comes from the trusted and known Identity Provider, then it will run a set of rules taking input claims from the Identity Token and produces output claim which tells what the user can do and what not.
5. The ACS issues an Access Token to the client. This Access Token issued for a particular Realm and for particular audience (i.e. service).
6. Finally the client raise request to the actual service with the Access Token for getting the required response.
7. The Service verifies up the Access Token and the access rights. If successful, the service produces the response and return back to the client.

Authentication and Authorization without Identity Providers
In some cases, we might not use any Identity Providers such as Live Id, Google Id, ADFS or custom STS providers. In that scenario, ACS provides the identity model on its own by enabling to create Service Identities such as User Name, Password on ACS itself. The functionalities of Authentication and Authorization, everything is same except the first two steps which get the Identity Token from the Identity Provider. The functionalities on ACS with the Service Identities will be as follows –

1. As there is no Identity providers to get authenticate the users, the User credentials (such as User Name, Password or Key) will be directly provided to the ACS from the client with the Realm for authentication.
2. The ACS verifies the credentials and evaluates the rules.
3. The ACS passes back the Access Token to the client.
4. The client requests the service with the Access Token.
5. The service verifies the Access Token and responds to the client the identity has the access right.

The ACS and Relying Party

As we seen previously, the ACS provides the Access Token to the client and client forward the Token to the Service with the request. The Service evaluates the Access Token and get to know that is provided by the ACS, for what Realm and the user access rights. So the Service delegates the authentication and authorization to the ACS.

As defined in the above figure the ACS and the Service shares a secret crypto signature key and client won’t know it. So when the ACS provides the Access Token to the client, it will sign the token with the shared key (which is known by ACS and Service) and when the client gets the request with the token, it can decrypt with the key and get to know the information.

(Note: The diagram is taken from msdn URL - http://msdn.microsoft.com/en-us/library/ee725241.aspx. I explained below steps which I got from the same URL – any errors pls comment.)

Step 0: For exposing a service to the public, we required to create a Service Bus namespace. The namespace can be created from Management portal under Service Bus, Access Control and Caching section. Once the Service Bus namespace created, the Azure environment provides an endpoint which can be used for exposing and consuming services using Service Bus and a default signing key which can be used for authentication and authorization while using service.

Step 1: Define Access Control rules for a Service Consumer The ACS portal is used for defining the security configuration such as Relying Party Application, Rules, Service Identities for the namespace created. To define the security configurations for a Service Bus namespace, select the Service Bus namespace and select the Access Control Service icon on the ribbon tab. The portal will open the Access Control Service portal for the namespace selected. By default, the Service Bus namespace will be secured by ACS portal for the base endpoint. For Example, if we have a Service Bus namespace dntpurchasemodule, the base endpoint http://dntpurchasemodule.servicebus.windows.net/ will be secured with the owner identity which uses SWT token format for handling authentication and authorization. To secure endpoints that has some sub paths such as http://dntpurchasemodule.servicebus.windows.net/order/, it is possible by creating a different Relying Party Application under the same namespace with the token format and defining the roles for the same. The issuer owner and key will be created by default and will have full access to the entire service for doing any operation. Normally when exposing and consuming services, it is recommended to not use owner identity as it has full access to the service. Instead it is better to create additional service identities with minimum access rights and use them while exposing and consuming. It is good to have different service identities while exposing the service and consuming the service. If different customers are using the service with different roles, better to create separate identities for each of them.

Step 2: Send Claims to AC in Exchange for a Token To access a service registered with AC, the service consumer required to provide a security token obtained from ACS. There are three ways to obtain the security token from ACS,

1. Plain Text – Sending a plain text user name/password (called issuer key) directly to AC for authentication.
2. Signed SWT – First Service Consumer required to create a token using an issuer name and key parameter, sign it and use the signed token to authenticate with AC.
3. SAML token – Sending an ADFSv2 issued SAML token with issuer key for authentication.

For more information pls refer the following links http://msdn.microsoft.com/en-us/library/ee706734.aspx

Step 3: Map Input Claims to Output Claims Using Rules and Issue a Token Once the authentication request received by AC, it identifies the input claims from the token request and match with the existing rules created already. When any of the rules matches, AC creates the output claims for the response. Then it creates a token that contains the output claims with the signing key registered.

Step 4: Return the Token to the Service Consumer Once the output token create by the AC, it returns that token to the Service Consumer as a response to the request raised in Step 2.

Step 5: Send a Message to the WCF Service with the ACS Token After receiving the token from the AC, the Service Consumer validates the token and checks the claims using the signing key. If the token is valid and required claims are present, the service consumer can access the service otherwise access will be denied.

From the next post, I will explain by creating a Service Bus namespace and providing necessary access controls.

We will also look at creating a WCF Service and exposing to the public using the Service Bus namespace which will be secured by AC. The Service Consumer will consume with different access credentials to see the output and access rights.

The other links on Securing WCF Services exposed on Azure Service Bus Namespace:

1. Securing WCF Services exposed on Azure Service Bus Namespace - Part 1
2. Securing WCF Services exposed on Azure Service Bus Namespace - Part 2
3. Securing WCF Services exposed on Azure Service Bus Namespace - Part 3
4. Securing WCF Services exposed on Azure Service Bus Namespace - Part 4
5. Securing WCF Services exposed on Azure Service Bus Namespace - Part 5
6. Securing WCF Services exposed on Azure Service Bus Namespace - Part 6