One of the services provided by the Windows Azure cloud computing platform is the Windows Azure Access Control Service (ACS). It is a service that provides federated authentication and rules-driven, claims-based authorization. It has some social providers like Microsoft Account, Google Account, Yahoo! and Facebook. But what about the other social identity providers out there? For example the newly introduced Login with Amazon, or LinkedIn? As they are OAuth2 implementations they don’t really fit into ACS.
Meet SocialSTS.com. It’s a service I created which does a protocol conversion and allows integrating ACS with other social identities. Currently it has support for integrating ACS with Twitter, GitHub, LinkedIn, BitBucket, StackExchange and Amazon. Let’s see how this works. There are 2 steps we have to take:
- Link SocialSTS with the social identity provider
- Link our ACS namespace with SocialSTS
Link SocialSTS with the social identity provider
Once an account has been created through www.socialsts.com, we are presented with a dashboard in which we can configure the social identities. Most of them require that you register your application with them and in turn, you will receive some identifiers which will allow integration.
As you can see, instructions for registering with the social identity provider are listed on the configuration page. For Amazon, we have to register an application with Amazon and configure the following:
- Name: your application name
- Application return URL: https://socialsts.azurewebsites.net/foo/amazon/authenticate
If we do this, Amazon will give us a client ID and client secret in return, which we can enter in the SocialSTS dashboard.
That’s basically all configuration there is to it. We can now add our Amazon, LinkedIn, Twitter or GitHub login page to Windows Azure Access Control Service!
Link our ACS namespace with SocialSTS
In the Windows Azure Access Control Service management dashboard, we can register SocialSTS as an identity provider. SocialSTS will provide us with a FederationMetadata.xml URL which we can copy into ACS:
We can now save this new identity provider, add some claims transformation rules through the rule groups (important!) and then start using it in our application:
Enjoy! And let me know your thoughts on this service.
This is an imported post. It was imported from my old blog using an automated tool and may contain formatting errors and/or broken images.