MYOC - Enabling Federation on Azure Applications using Windows Identity Foundation
As a part of the current work we are trying to provide Federated Authentication in Azure Application. We want to develop a web application in Azure which would outsource authentication service to another component which would in turn authenticate users with its own enterprise. The basic idea is to be able to provide access to authenticated users from trusted organizations. As a sample we will use MyCompany as one of the trusted organizations.
To achieve this we explored Windows Identity Foundation (previously called as Geneva Framework). Windows Identity Foundation provides Claims based Identity Management. It means the applications would have only authorization logic as per the claims (attributes) of the users since these claims are certified by a trusted source; these claims are secured also and hence can be trusted by the authentication mechanism. Using this framework authentication can be outsourced to some other central application or central storage and develop a claim aware application. Hence there is no need to bother about plumbing of the authentication code; one can just make use of the trusted claims received from the application which takes responsibility for authentication.
You might have got the point; this claims based model can be extended to achieve Enterprise SSO / Web SSO / Federated Authentication.
Before drilling down into the solution let us get introduced to some basic terminologies used in Windows Identity Foundation:
Term | Definition |
claim | A statement that one subject makes about itself or another subject. For example, the statement can be about a name, identity, key, group, privilege, or capability. Claims are given one or more values, and then they are packaged in security tokens that a security token service (STS) issues. |
claim type | The type of statement in the claim that is made. Example claim types include FirstName, Role, and Date of Birth. The claim type provides context for the claim value. |
claim value | The value of the statement in the claim that is made. For example, if the claim type is FirstName, a value might be Matt. |
digital identity | A set of claims that represent a subject. |
identity provider | An organization that issues claims in security tokens for a particular transaction. For example, an identity provider, such as a university, might issue a claim in a security token that enables one of its students to purchase books and materials from the university’s Web site that is managed by a contracted relying party organization. |
identity provider security token service (IP-STS) | A software component or service that an identity provider uses that issues claims and then packages them in security tokens. |
policy | A set of parameters that an STS requires to identify relying parties, identity providers, certificates, account stores, claims, and the various properties of these entities that are associated with the STS. |
relying party | An organization that uses the claims in security tokens that an identity provider issues. For example, an online auction Web site organization might receive a security token with claims that determine whether a subject can access all or part of a relying party's application. |
relying party application | Software that can consume claims in security tokens that an identity provider issues to make authentication and authorizations decisions. |
relying party security token service (RP-STS) | A software component that uses the claims in security tokens that an IP-STS issues. The RP-STS receives the security token, verifies the signature, maps the claims, and then generates and signs new security tokens that a relying party application consumes. |
security token | A collection of one or more claims. Security tokens are usually packaged in standard formats for interoperability. Common formats for security tokens include Security Assertion Markup Language (SAML), X.509, and the Kerberos authentication protocol. |
security token service (STS) | A software component that is used to issue claims and packages them in security tokens. |
subject | A person, organization, or thing that is described or dealt with. |
Active Clients | Active clients refer to the smart clients who are capable of executing the claims services by their own. In this case clients retrieve the policy for Relying Party calls the service from STS to get claims and submit the claims back to the Relying party. Policy, Claims retrieval and submission logic is implemented by client itself. |
Passive Clients | Passive clients refer to the web browsers which do not have capability to execute code by their own. In this case The user points his browser at a claims-aware web application (relying party). The web application redirects the browser to the STS so the user can be authenticated. The STS authenticates the user via standard HTTP mechanisms, and then creates a SAML token and emits a bit of JavaScript that causes the browser to initiate an HTTP POST that sends the SAML token back to the relying party. |
Let us try to make it clearer with a diagram and flow of events with a scenario.
Scenario: A user should be authenticated with his/her Active Directory credentials when he/she tries to access a web application. This scenario can be extended, to be able to get users authenticated with their own enterprise active directory domain.
Note: When we started realizing this scenario, “Geneva Server” (Now called as ADFS) was not supporting Integration with Azure based application. The implementation of exposing authentication service over .Net Service Bus is a workaround to overcome the issue. Still, the concepts of Windows Identity Foundation, ACS and STS are relevant.
Diagram1: Federated Authentication Flow – Explained with Roles
- User /Subject sends a request to access the Claims Aware App (Relying Party)
- Claims Enabled Client Application is configured to receive the token from .Net Service Access Control (RP-STS) but Identity Provider is Custom IPSTS, hence the request redirects to Custom IPSTS which is acting as IP-STS here
- a. Custom IPSTS renders forms authentication screen where user needs to select the domain to which he/she belongs to. Internally, as per the domain selection Custom IPSTS application calls the respective .net service passing user name and password to the service bus. This communication is secured using transport security. Microsoft best practice is to also use the message level security.
- b. .Net service bus is configured to call the respective on premise authentication service. Once the on premise service authenticates the users, it returns the authentication flag to IPSTS
- After authentication IPSTS issues a Security Token which contains User’s/Subject’s claims, in our case it is user name
- As per the configuration the Claims received from the Custom IPSTS gets passed to Access Control Service (RP-STS). Trust relationship between ACS and Custom IPSTS is already setup by means of certificate policy
- Access Control Service then validates the issuer and transforms the claims. Transformation includes generating new set of claims from issued claims and asserting its own security token. The transformation of Claims is called as Rule in ACS. Note that Relying Party must get claims/Security Token from configured ACS only
- Claims/Security Token/Digital Identity issued by ACS (RP-STS) is passed to Claims Aware App (RP) which validates the issuer and trusts the token. Provides access as per the claims received
Let’s map sample applications to the specific role and drill down into the implementation specifications
Application | Purpose | Application Deployment |
Claims enabled application. Relying party to token issued by ACS | Web Role Deployed in Azure | |
RP-STS- Relying Party Security Token Service which issues the token to Claims Enabled Application | Azure Access Control Service configured with an application id | |
Custom IP-STS – Identity Provider Security Token Service which is responsible for issuing authentication token to ACS RP-STS | Another Web Role deployed in Azure | |
https://mynetservice.servicebus.windows | On premise authentication service end point registered on the .Net Service Bus. This service is consumed by customIPSTS to authenticate users | A custom .net Service bus running on premise and registered with Azure .Net Service Bus configured with an application id |
Diagram2: Federated Authentication Flow – Explained with sample Applications
Let us revisit the flow, this time with applications and not with only the roles
- User/Subject wants to access a web application from his/her browser, sends a request to access to http://myoc.cloudapp.net
- http://myoc.cloudapp.net is configured to receive the token from .Net Service Access Control https://mynetservice.accesscontrol.windows.net but Identity Provider is Custom IPSTS, hence the request redirects to https://customIPSTS.cloudapp.net
a. Custom IPSTS renders forms authentication screen where user needs to select the domain to which he/she belongs to. Internally, as per the domain selection Custom IPSTS application calls the respective .net service https://mynetservice.servicebus.windows.net/SecuredAuthService/ passing user name and password to the service bus. This communication is secured using transport security
b. https://mynetservice.servicebus.windows.net/SecuredAuthService/ .Net service bus is configured to call the respective on premise authentication service. Once the on premise service authenticates the users, it generates a forms based authentication cookie and returns the authentication flag to Custom IPSTS - After authentication Custom IPSTS issues a Security Token which contains User’s/Subject’s claims, in our case it is user name
- As per the configuration the Claims received from the Custom IPSTS gets passed to Access Control Service (RP-STS) https://mynetservice.accesscontrol.windows.net. Trust relationship between ACS and Custom IPSTS is already setup by means of certificate policy
- Access Control Service then validates the issuer and transforms the claims. Transformation includes generating new set of claims from issued claims and asserting its own security token. Note that Relying Party must get claims/Security Token from configured ACS only
- Claims/Security Token/Digital Identity issued by ACS (RP-STS) is passed to Claims Aware App (RP) http://myoc.cloudapp.net which validates the issuer and trusts the token. Provides access as per the claims received
Implementation stack
Component | Implementation |
Custom IPSTS | Renders forms based authentication user interface, which is secured by https. Consumes .Net Service to validate user. Implements Windows Identity Framework’s custom Security Token Service to generate custom claims. Also exposes Claims Policies and Federation Metadata for ACS or any consumers |
ACS | Azure Service where we need to register the Relying Party as consumer, Custom IPSTS as issuer. Need to configure rules for claims transformation |
Authentication Service | This component exposes an end point on .Net service bus and responsible for authenticating users, generating forms based cookie |
MYOC application | Relying party which depends on ACS tokens for authentication and uses the claims for authorization. Implements Windows Identity Framework Passive Federation with ACS and Custom IPSTS configured for authentication |
I hope this briefly explains about the custom federation achieved using Windows Identity foundation. In the next post we shall get into the nitty-gritty’s of each of these implementations and configurations to achieve federation with Azure applications.
