This post discussing how it is possible to publish applications to Internet based users who authenticate to the UAG via one of the Internet Cloud Identity Providers, such as LiveID, Google, Yahoo or Facebook. The Windows Azure ACS acts as IdP-STS in this configuration topology.
This is essentially the same as what we discussed in the previous configuration, where we published applications to partner organizations. The key difference here is that we do not actually have a specific individual organization. In this configuration, we are able to provide access to our applications to anyone who already has an identity at one of the big Cloud Identity providers – Microsoft LiveID, Google, Yahoo and Facebook. This accounts for millions of users.
The Microsoft Cloud development platform, Azure, provides this very unique capability via Azure Access Control Services. Azure ACS is configured to use these four identity providers as a potential authentication source. Very minimum configuration is required. Azure ACS must be configured as a trusted Identity provider with our internal RP-STS. From there on, the authentication is very similar to Federated WebSSO.
After the user tries to access the published application, he will be redirected to the RP-STS. Home Realm Discovery will be done at this point, and the user will be redirected to the Identity Provider, in this case Azure ACS. Depending on how Azure ACS is configured, it will redirect the user to one of the Cloud providers or it will give the user the option to choose one of them. The user will authenticate to the Cloud Identity provider and will be redirected back to Azure ACS, which, in turn, will create a SAML security token, provide it to the user, and from there on it will be posted back to RP-STS, transformed, and provided to the target application. Figure 1 shows the high level configuration for this topology.
Figure 1: Azure ACS in Federated WebSSO