Federated Identity Access to Windows Azure Service Bus

Identity Federation is all about trusts. As the diagram shows below, all participants within such identity federation form a cycle of trusts. One can easily extend federated authentication for Windows Azure Service Bus to external user communities with social identity, Windows Azure Active Directory (WAAD) tenant’s cloud identity, or business partner’s identity. It also supports federation protocols such as SAML-P, WS-Fed and OpenID.

In the scenario above, the client application is implemented as claim-aware and accessible to the end users with federated identity mentioned as above. Once the user logs in to the client application, the user leverages the Windows Azure Service Bus to perform business tasks.

Active Directory Federation Service (ADFS) acts as an identity provider for internal users (employees) and as a security token service (STS) for external users with federated identity. In this post, STS is described as an authentication broker that not only handles security token generation but also handles security token exchange and transmission. The relationship between WAAD and Windows Azure Access Control Service (ACS) is similar to ADFS as an identity provider
role and as a security token service role. In addition, ACS can also be an identity provider role, one of STS roles, with its own service identities.

In order for a client to work with Azure Service Bus, they can obtain a SAML token from ADFS. The client presents the SAML token to the Service Bus auto created ACS (SB ACS) for exchanging it as an SWT token. Then the client sends the request to Service Bus along with the SWT token.

In the simplest implementation, the client is secured by ADFS as a relying party and receives claims once the user is authenticated. Then, the client uses WS-Trust to get a SAML token applied to SB-ACS from ADFS. This implementation disconnects caller’s identity (the identity with credentials used in WS-Trust). Again one needs to maintain the integrity between these two separated identities, if the subject’s claim information is important to be known by the service.

Alternatively, the client can impersonate the end user by utilizing Return URL as a means to consume either a SAML token applied to SB-ACS or SWT token applied to Azure Service Bus within single subject’s identity context.

Let’s walk through the business partner’s use case with SAML-P Identity Provider.

1. User attempts to access client application
2. Client redirects unauthenticated request to ADFS
3. User selects SAML-P IdP during Home Realm Discovery (HRD) process
4. ADFS sends SAMLRequest message to SAML-P IdP
5. SAML-P IdP authenticates user
6. SAML-P returns SAML token to ADFS
7. ADFS generates new SAML token based on claim rules
8. Browser auto posts new SAML token to client
9. Client presents new SAML token to SB-ACS
10. SB-ACS exchanges SAML token as SWT token based on claim rules
11. Client presents SWT token with the service request to Azure Service Bus
12. Azure Service Bus validates the token and allows the request to pass to the required service

The similar process goes from other identity providers such as Social IdP or WAAD tenant instance via Windows Azure ACS as federation provider to ADFS. WAAD also implements SAML-P as identity provider, as long as RelayState is supported. For such cases, one can setup a federation trust relationship between WAAD as identity provider and ADFS as service provider using SAML-P term.