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.

Many API’s out there, such as GitHub’s API, have a concept called “rate limiting” or “throttling” in place. Rate limiting is used to prevent clients from issuing too many requests over a short amount of time to your API. For example, we can limit anonymous API clients to a maximum of 60 requests per hour whereas we can allow more requests to authenticated clients. But how can we implement this?

Intercepting API calls to enforce throttling

Just like ASP.NET MVC, ASP.NET Web API allows us to write action filters. An action filter is an attribute that you can apply to a controller action, an entire controller and even to all controllers in a project. The attribute modifies the way in which the action is executed by intercepting calls to it. Sound like a great approach, right?

Well… yes! Implementing throttling as an action filter would make sense, although in my opinion it has some disadvantages:

• We have to implement it as an IAuthorizationFilter to make sure it hooks into the pipeline before most other action filters. This feels kind of dirty but it would do the trick as throttling is some sort of “authorization” to make a number of requests to the API.
• It gets executed quite late in the overall ASP.NET Web API pipeline. While not a big problem, perhaps we want to skip executing certain portions of code whenever throttling occurs.

So while it makes sense to implement throttling as an action filter, I would prefer plugging it earlier in the pipeline. Luckily for us, ASP.NET Web API also provides the concept of message handlers. They accept an HTTP request and return an HTTP response and plug into the pipeline quite early. Here’s a sample throttling message handler:

 1 public class ThrottlingHandler
 2     : DelegatingHandler
 3 {
 4     protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
 5     {
 6         var identifier = request.GetClientIpAddress();
 7 
 8         long currentRequests = 1;
 9         long maxRequestsPerHour = 60;
10 
11         if (HttpContext.Current.Cache[string.Format("throttling_{0}", identifier)] != null)
12         {
13             currentRequests = (long)System.Web.HttpContext.Current.Cache[string.Format("throttling_{0}", identifier)] + 1;
14             HttpContext.Current.Cache[string.Format("throttling_{0}", identifier)] = currentRequests;
15         }
16         else
17         {
18             HttpContext.Current.Cache.Add(string.Format("throttling_{0}", identifier), currentRequests,
19                                                      null, Cache.NoAbsoluteExpiration, TimeSpan.FromHours(1),
20                                                      CacheItemPriority.Low, null);
21         }
22 
23         Task<HttpResponseMessage> response = null;
24         if (currentRequests > maxRequestsPerHour)
25         {
26             response = CreateResponse(request, HttpStatusCode.Conflict, "You are being throttled.");
27         }
28         else
29         {
30             response = base.SendAsync(request, cancellationToken);
31         }
32 
33         return response;
34     }
35 
36     protected Task<HttpResponseMessage> CreateResponse(HttpRequestMessage request, HttpStatusCode statusCode, string message)
37     {
38         var tsc = new TaskCompletionSource<HttpResponseMessage>();
39         var response = request.CreateResponse(statusCode);
40         response.ReasonPhrase = message;
41         response.Content = new StringContent(message);
42         tsc.SetResult(response);
43         return tsc.Task;
44     }
45 }

We have to register it as well, which we can do when our application starts:

1 config.MessageHandlers.Add(new ThrottlingHandler());

The throttling handler above isn’t ideal. It’s not very extensible nor does it allow scaling out on a web farm. And it’s bound to being hosted in ASP.NET on IIS. It’s bad! Since there’s already a great project called WebApiContrib, I decided to contribute a better throttling handler to it.

Using the WebApiContrib ThrottlingHandler

One word of warning: at the time of writing this post, the ThrottlingHandler pull request was not accepted yet. If you want it now, please find it in my fork on GitHub.

The easiest way of using the ThrottlingHandler is by registering it using simple parameters like the following, which throttles every user at 60 requests per hour:

1 config.MessageHandlers.Add(new ThrottlingHandler(
2     new InMemoryThrottleStore(), 
3     id => 60, 
4     TimeSpan.FromHours(1)));

The IThrottleStore interface stores id + current number of requests. There’s only an in-memory store available but you can easily extend it to write this in a distributed cache or a database.

What’s interesting is we can change how our ThrottlingHandler behaves quite easily. Let’s give a specific IP address a better rate limit:

 1 config.MessageHandlers.Add(new ThrottlingHandler(
 2     new InMemoryThrottleStore(), 
 3     id =>
 4         {
 5             if (id == "10.0.0.1")
 6             {
 7                 return 5000;
 8             }
 9             return 60;
10         }, 
11     TimeSpan.FromHours(1)));

Wait… Are you telling me this is all IP based? Well yes, by default. But overriding the ThrottlingHandler allows you to do funky things! Here’s a wireframe:

1 public class MyThrottlingHandler : ThrottlingHandler
2 {
3     // ...
4 
5     protected override string GetUserIdentifier(HttpRequestMessage request)
6     {
7         // your user id generation logic here
8     }
9 }

By implementing the GetUserIdentifier method, we can for example return an IP address for unauthenticated users and their username for authenticated users. We can then decide on the throttling quota based on username.

Once using it, the ThrottlingHandler will inject two HTTP headers in every response, informing the client about the rate limit:

It’s a first version, I do hope the pull request gets in. In the meanwhile, enjoy! And do checkout WebApiContrib, it contains almost all extensions to ASP.NET Web API you will ever need!