This is a series of post explains about securing the WCF Service which is exposed to public on Azure Service Bus. Look at the end of this post for other parts.
ACS – Relying Party Applications
Relying Party Application is a service or an application or a web site in ACS, which is used for delegating the authentication and authorization process to ACS for a particular Realm. This Relying Party Application relies on claims and it evaluates the input claims and produces an output claim by running some rules. The rules are created when Relying Party Application created, which explains for what types of input claims (For Ex: user name, email address) what equal output claims(access rights).
To create a relying party application in ACS, it requires a Realm – an URI for which the Relying Party issues the token. The realm URI can be an URL (Ex: http://www.fabrikam.com/billing) or an URN (Ex: urn:fabrikam:billing).
For Ex: When I create a Service Bus Namespace known as dntsales, there will be an ACS namespace dntsales-sb (suffixed with –sb) associated with that Service Bus namespace by default and configured a relying party application with http://dntsales.servicebus.windows.net/ as realm URI.
Realm URI Hierarchies
The URI can be declared with different hierarchies as we defined in the Service Bus endpoints.
For Ex: The realm URI for a relying party application can be as follows
http://dntsales.servicebus.windows.net/Http/Order/Test/V0101/
http://dntsales.servicebus.windows.net/US/East/POP/Order/
Note: When defining the Service Bus hierarchies, it is good practice to follow a standard at organization level and that can be used in Relying Party applications definitions. Below is a post explains a practice for deciding the hierarchies for service bus endpoints.
https://thirumalaipm.blogspot.com/2012/01/implementing-azure-appfabric-service.html
Below figure shows an example of the hierarchical form of a namespace endpoints
When any request comes to ACS directly from the client (or from identity provider), the ACS will matches the realm value from the token with the ACS realm configured with the relying party application using longest prefix match model. The relying party which matches (with incoming realm), will take into consideration for processing authentication and authorization.
For Ex: I have three Relying Party applications with the following Relying Party definition under an ACS namespace dntsales. They are -
| Relying Party Application name | Realm URI |
| ServiceBus | https://dntsales.servicebus.windows.net/ |
| Orders | https://dntsales.servicebus.windows.net/Orders/ |
| OrderHttpEndpoint | https://dntsales.servicebus.windows.net/Http/Order/Test/V0101/ |
The ACS will match with these three Realms when a request reached from the client.
- A request with https://dntsales.servicebus.windows.net/ realm will be served with ServiceBus Relying Party Application.
- A request with https://dntsales.servicebus.windows.net/Sales/ realm will also be served with Service Bus Relying Party Application only. Because the other two Realm URIs are different.
ACS and Service Identities
ACS Service Identities are credentials which are in the form of Password, Symmetric Key or an X509 Certificate, which is used to authenticate the request.
To understand, service identity acts as an object (or a person) that is used to authenticate the request from client and inform to ACS the user is valid and the access rights can be done with the identity.
As we seen already, when a Service Bus namespace registered with Azure there will be a Relying Party Application created automatically. That relying party application will be linked with a rule groups (explained next) and each rule can be linked with a service identity known as owner by default. Owner is a service identity which is a super user that has Send,Listen,Manage access rights to do management operations on the ACS namespace.
The developer can create more service identities if required and can assign different access rights to them. In this way, each customer can own a different unique service identity which has minimum access rights on the service bus namespace.
ACS and Identity Providers
Identity providers are services which are used for authenticating the users. By default ACS portal provides some build in identity providers such as Windows Live ID, Google ID, Yahoo Id, Facebook Id. The developer can add more identity provides such as ADFS, Open ID etc by using WS-Federation identity providers. The requirement for adding other providers is, those must support WS-Federation or WS-Trust protocol.
When a client requests ACS with a realm, ACS first checks the coming request is with security token or not. If no security token found, the ACS return to the browser requesting security token. The browser will redirect to the login page (which has list of identity providers configured with the ACS namespace) and authenticate with any of the identity provider. The Identity provider will return a security token to the browser and the browser will again request ACS with security token. The ACS look at the security token is valid and comes from trusted provider. If yes, it will take the request for further process.
In some case, there may be a scenario where there is no identity provider configured and the other way to call the ACS with the service identity token configured with ACS namespace.
ACS and Rule groups
Rule Groups in ACS contains a list of rules, each of which defines the input claims and the corresponding output claims. This mapping defines for what types of input claims, what should be the output claims for the relying party. This is required because, the client application might not know the all the claims comes from the Identity providers (such as Google, Yahoo, Facebook etc.,). So by defining this rule, the rule engine creates output claims which can be understandable by client application. The rule engine can also decide the Authorization based on the rules defined in the Rule Groups.
Rule Groups is linked with one of more Relying Party Application and a Rule Groups can have more then one Rule Group defined. Each Rule Group can have one or more claim rules, which has input claims and an output claim that describes how the input claims can be transformed into output claims.
For Ex: If the Service Identity Name is thiru, then the identity has rights to listen. Here thiru will be the input claim and listen (the action) will be the output claim.
When a client needs authentication and authorization, it first submits the Identity token (which was received from Identity Provider - if any third party provider used) or sends the service identity credential to ACS (if client calls directly) with a Realm URI. The ACS maps the Realm with the Relying Party Application using longest possible match method. When ACS found a Relying Party Application, it evaluates all the Rule Groups and gets the output claims as the result of the rules. The output claims are used for issuing the Access Token.
ACS and Access Rights
There are three possible access rights available with ACS, which can be defined using net.windows.servicebus.action namespace. They are –
- Send – Can send request to the service bus endpoint and wait for response. The client can use the identities which has Send access right.
- Listen – Listen the request from the service bus endpoint and respond back to the client. The service applications use the identities which has Listen rights.
- Manage – Permits management operations such as Create, Inspect and Delete Service Bus entities.
It is also possible to add and remove the Rules Groups which was created already (when creating other relying party application).
For Ex: I created a Service Bus namespace dntsales. Azure automatically created an ACS namespace dntsales-sb and associate with the dntsales Service Bus namespace.
By default, the dntsales-sb namespace will have a Relying Party Application (Name: Service Bus) with the base URI of Service Bus https://dntsales.servicebus.windows.net/. There will also be Rule Groups and Service identities created by default.
Below picture shows conceptual view of ACS components -
Rule Group Hierarchies
When creating a Relying Party Application, there is an option to create one Rule Group and associate the same for that Relying Party Application.
So, if we define a Service Identity has rights in parent Relying Party Application and referred in the child Relying Party Application.
Below figure shows how the Rule group inherited from parent node Relying Party Application -
/ => This Relying Party application is for base Realm (Ex: http://dntsales.servicebus.windows.net/). By default the system will create owner identity and give Send, Listen and Manage claims.
/Orders/ => This application is referring the parent Rule Groups (/) and It does not define any more special claim in its own Rule Group. So the same Rules are been inherited from the parent Rule Group.
/Orders/Purchase/ => Inherited from parent Rule Group, and it has one special claim defined in its own Rule Group defined (Service Identity abc has Listen claim). So owner has Send, Listen and Manage claims and abc has Listen claims for this realm.
/Orders/Purchase/India/ => Not inherited from parent Rule Group, and it has a special claim defined in its own Rule Group (Service Identity cde has Send claim). So it has only one claim Send for cde Service identity.
/Orders/Sales/ => Not inherited from parent and has a single claim defined. So it has only Send claim for efg identity.
/Orders/Sales/US/ => Inherited from parent and no special claims defined in its Rule Group. So it has only Send claim for efg identity.
/Invoice/ => Not inherited from parent and has two claims defined in its own Rule Group. So totally it has Listen claim for abc and Send claim for efg.
/Invoice/Sales/ => Inherited from parent and no claim defined in its Rule Group. So it has two claims abc with Listen and efg with Send.
/Invoice/Sales/India/ => Inherited from parent and no claim defined in its Rule Group. So it has two claims abc with Listen and efg with Send.
/Invoice/Purchase/ => Inherited from parent and has one more claim in its Rule Group. So totally it has Listen claim with abc and pqr, Send claim with efg.
/Invoice/Purchase/US/ => Not inherited from parent and has two claims defined in its Rule Group. So it contains Listen with abc and Send with def. Here abc:Listen defined it its own rule group and not inherited.
Please refer the Defining Rule section in the below URL to know more about what are the claims possible for a particular Service Bus related operations such as Send a message to Service namespace, Listen at a particular Service name etc.
http://msdn.microsoft.com/en-us/library/hh403962.aspx
From the next post, we will see the implementation of exposing a service to public and manage the access using ACS.
The other links on Securing WCF Services exposed on Azure Service Bus Namespace:
- Securing WCF Services exposed on Azure Service Bus Namespace - Part 1
- Securing WCF Services exposed on Azure Service Bus Namespace - Part 2
- Securing WCF Services exposed on Azure Service Bus Namespace - Part 3
- Securing WCF Services exposed on Azure Service Bus Namespace - Part 4
- Securing WCF Services exposed on Azure Service Bus Namespace - Part 5
- Securing WCF Services exposed on Azure Service Bus Namespace - Part 6
0 Responses to “Securing WCF Services exposed on Azure Service Bus Namespace - Part 2”
Post a Comment