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.
Securing the Service Bus endpoint can be done multiple ways, some are
- Authentication using public Identity Provides such as Live Id, Google Id, Yahoo Id, Face book etc. In this model, the user required to get authentication from the public identity provides and successful authenticated users can access the application. This model can be used in any application which is targeting to public users similar to EBay.com, amazon.com, flipkart.com etc.,
- Authentication using ADFS (Active Directory Federation Service), where the AC will redirect to ADFC federation URL and the authenticated user can access the application. This model can be used for enterprise application very much.
- Another way to authenticate use is to create service identities (such as user id, password) in the Access Control Service itself. This provides a way to keep the entire user database in the ACS and authentication and authorization can be done using the same.
- Another way is to provide the certificates for authenticate and authorization.
In this post, I am planning to explain creating Service Bus namespace and adding service identities using Access Control Service portal.
Before going for the actual steps, we required to finalize the endpoints that need to be exposed when exposing the service on public. We can expose multiple services under a single namespace with different hierarchy paths. So when any service exposed on Service Bus, it will be exposed with different path addition to the base endpoint.
For Example - when PurchaseOrder service exposed on Service Bus namespace dntsales, the public endpoint URI can configured by adding some paths to the base endpoint such as http://dntsales.servicebus.windows.net/Order/.
As I mentioned in the previous post, it would be nice if some guidelines followed on naming the endpoint URI. For more information please refer the post https://thirumalaipm.blogspot.com/2012/01/implementing-azure-appfabric-service.html.
In this example, I am planning to expose the PurchaseOrder service on Service Bus with the following endpoint URLs.
https://dntsales.servicebus.windows.net/Http/Order/Test/V0101/ - for https endpoint
sb://dntsales.servicebus.windows.net/Tcp/Order/Test/V0101/ - for tcp endpoint
Creating a new Service Bus Namespace
Step 1: The first step is to create a Service Bus namespace. I had already blogged on creating Service Bus namespace previously, so please look at the following URL for the same.
https://thirumalaipm.blogspot.com/2012/01/implementing-azure-appfabric-service.html
For this example, I am planning to create Service Bus namespace as dntsales.
Step 2: Select the namespace and press Access Control Service from the ribbon tab. The portal will redirect to Access Control Service portal.
Adding New Service Identities
Step 1: Before configuring Relying Party Applications, we have to create Service Identities which is used for authentication and authorization of the service.
So select the Service Identities from the left panel.
Step 2: Press Add hyperlink to add a new identity. The portal will open the Add Service Identities screen.
Step 3: Add the following inputs and press Save.
Press Generate button to generate the key.
Step 4: Press the Save button in the Edit Service Identities screen.
Step 5: To add a second identities, press Add hyperlink and provide the following details.
Step 6: Save the details in the Add Service Identity and then Edit Service Identity screen.
Step 7: Now you can see two additional identities in the Service Identities list.
Now we have added two service identities, one can be used for sending the request from client to listener and another one is to listen the request which is coming on the service namespace from the service.
Adding Relying Party Applications
Relying Party Application is an application, a service or a web site used for configuring the endpoint which refers for authenticate and authorize from AC, token format etc.,
Step 1: Now we required to add relying party applications for the endpoints we are exposing to the services. So to add a new relying party application, select the Relying Party Applications from the left navigation.
By default, the portal will show a Relying party application (ServiceBus) for the base service bus endpoint URL (http://dntsales.servicebus.windows.net/) with SWT Token format.
Step 2: Press Add link. The portal will show Add Relying Party Application entry screen.
Step 3: We have two endpoints on which the WCF Service is exposed; one is with Http and another in TCP binding. So we have to create two Relying Party Applications – one for each of them.
In this step, I am taking https endpoint and configuring the Relying Party Application. So provide the following inputs in the entry fields and save the entry.
Name: Service Bus Authentication with Service Identity for Http Endpoint.
Mode: Enter settings manually.
Realm: This is the entry for specifying the Service Bus endpoint URL of exposing the service. As I am exposing the service with following endpoint URL, specify the same.
http://dntsales.servicebus.windows.net/Http/PurchaseOrder/Test/V0101/
Return URL: This entry is for specify the URL on which the security token to be returned back from AC. It is an option when Realm and Return Realm is same. So leave the field empty.
Error URL (optional): This entry is for specifying the URL when any error happened in the AC. Leave the field empty.
Token format: This entry is for specifying the token format issued by AC. It can be SWT, JWT, SAML 1.0 and SAML 2.0. This example use SWT, so keep the same selection.
Token encryption policy - None
Token lifetime (secs) – Leave the value as it is.
Identity providers – As we are going to specify the user name and password directly in the portal and not using any identity provides such as Live ID, Google Id etc. So, unselect all the identity providers.
Rule groups – Select Create new rule group check box.
Token signing key – Press Generate button to create a new signing key.
Effective date, Expiration date – Verify the effective date starts from today and expiration date ends in future.
Step 4: Press Save button to save the details. The portal will save the details and show the Relying Party Applications screen with the added relying party in a list.
Adding Rule Groups
Rule Groups is used for configuring the input and output claims. When request comes from client for authentication and authorization, AC checks the input claims from the request and if matches successfully it will return the token format based on the output claims defined in the Rule Groups.
Step 1: Select the Rules Groups from the left panel. The portal will show two rows in the list, one with Default Rule Group for Service Bus and another one is the Default Rule Group for the newly added relying party application.
Open the newly created Rule Group from the list by selecting the link. It will open the Edit Rule Group screen.
Step 2: Select the newly added Default Rule Group from the list in the Rule Groups screen which will take you to Edit Rule Groups screen.
Step 3: Click Add hyperlink to add a new rule and provide the following input in the Add Claim Rule screen.
As you see here, we have the rule – if request (input) claim name is thiru, he is authorized to send the message to the service namespace. So, thiru is the service identity which we will be used for sending the request from client.
Step 4: The above rule specify who can send the message; we need one more rule who can listen the message. So click again Add from the Edit Rule Groups screen and add a new rule as defined below.
Step 5: Now you can see two rules added in the Edit Rule Group screen as below. Press Save button to save the rules group in the Edit Rule Groups screen.
Adding another Relying Party Applications
We have added one relying party application for Http endpoint. We required to add one more relying party application for Tcp endpoint as well.
Note: I am planning to expose the service with two endpoints one with basicHttpRelayBinding and another one with netTcpRelayBinding. So the client can consume either of the binding it prefers. Incase if you expose with only one endpoint, adding Relying party application for that one is enough.
Step 1: Add a new Relying Party application as specified above steps with the following parameters.
Step 2: The next step is to add the Rule Group for the Relay Party Application added in previous step. So open the Rule Groups screen by selecting Rule Groups from left panel.
Step 3: Select the Default Rule Group hyperlink for the newly added Rule Group.
Step 4: Add two new rules by selecting Add hyperlink. The details are same as defined previously for adding rule groups for Http endpoint.
Step 5: Press Save button at the Edit Rule Group screen.
Now we have added required Relying Party Application and Rule Groups. So, we can consume the ACS when exposing and consuming the service.
Deleting Token Signing Keys
I am really not sure why we required to delete this Token Signing keys which was adding when Relying Party Application created. But the implementation works fine after deleting the Token Signing keys. If anyone knows the reason, please comment on this page.
Note: This deletion is applicable when the Service Identities created using Symmetric Keys.
Step 1: Select the Certificates and Keys from the left hand side.
The portal will show two token signing keys created (once for each Relying Party Application under Token Signing section.
Step 2: Select both the Token Signing Keys and press the Delete hyperlink on the top of the section.
Step 3: Confirm the Delete.
The AC will delete both the keys and remove the reference from the Relying Party Application.
The next post will explain the service application which is exposing to public on the Azure Service Bus namespace.
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 3”
Post a Comment