Token based security strategy and considerations

Question

I'm working on a security setup suitable for the following client/server scenario, and I'm having a couple of questions/considerations that I'd like to share with you.

Situation: I have a number clients on different platforms:

• HTML-client (single page apps (SPAs) using jQuery/AJAX)
• Android-app
• Silverlight client
• Windows client
• Windows Mobile client

The large majority of the corresponding server components are based on .NET WCF using REST (but for some backends, I'm using other protocols).

I've found the open source project IdentityServer v2 from ThinkTecture to be a nice and flexible security token service (STS) for my solution. It supports a number of token types, protocols and is highly extendable and has a self contained Identity Provider (IdP) based on ASP.NET Membership database if needed.

The basic flow for clients using usernames/passwords is as follows:

1. The client makes an unauthorized HTTP call to a ressource (that requires authorized access) on its server
2. As the client is not yet authenticated, the server returns a HTTP 401 (unauthorized) providing an address to the STS in an HTTP Location header (see note on this below)
3. The client submits its credentials to the STS in a HTTP Basic Auth header
4. The STS returns a JWT token containing all relevant user claims
5. The client now repeats its initial request from step 1 including the JWT token in the HTTP Auth Bearer header
6. The server validates the token, as it originates from a trusted STS source, and returns the requested ressource

I know that step #2 is a bit unorthodox in combining the HTTP 401 error message with a HTTP Location header normally associated with the HTTP 3xx status codes. I need the 401 status code because of my jQuery/AJAX clients which handle the 302 redirect message automatically without any chance to interscept the redirect.

Now, the system needs to use an external IdP. The "internal" STS is customized to forward auth requests to the external IdP handling transformation of claims from the external IdP format to the internal format. One catch with this is that it implies the "password anti-pattern", but for now all systems are interal and trustworthly.

Could WS Federation be my friend?

The above basic flow applies to at all clients, browser based or not. But for specifically browser clients, I've been looking into a federated security scenario, having the resulting IdP/STS to provide a login mechanism for the clients. The STS that I use (IdentityServer) can be configured to be used in conjunction with a WS-Federation compliant STS. Thereby tokens are automatically transferred to the target token format (in my case for instance from the external STS's SAML token to the internal JWT token). With this I can have some sort of a SSO mechanism.

Now my questions:

1. Is my described basic security flow optimal?
2. Is WS-Federation only applicable for browser clients?
3. If not, how can it be used with for instance my android clients?
4. In WS-Federation with more STSs, how is the communication flow between: client - internal STS - external STS (in terms of HTTP communication, cookies and stuff).

Answer 1

I don't think what you describe is WS-Fed. WS-Fed never involves 401 and never involves authentication headers.

WS-Fed has two versions, passive and active.

Passive is for browsers. It consist in 302 to the identity provider which in turn POSTs the SAML token back to the caller. The authenticaiton is then supported by cookies.

Active is for active clients (applications). It consist in a SOAP response that instructs the caller to go to the identity provider for the token. The SOAP response from the identity provider contains a token which is then supplied to the service.

What I believe is that the active scenario is quite complicated if your client doesn't support the WCF federation authentication binding (wsTrustFeb2005). You'd have to implement the flow on your own.

What I'd like to recommend instead would be the OAuth2 flow. OAuth2 has 4 different flows, of which two correspond to WS-Federation's active and passive: authorization code flow is for browser-based apps and the implicit flow is for desktop/mobile applications.

http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#authorization

OAuth2 integrates easily with WebAPI services and there is a great support for it in the DotnetOpenAuth library.

This and other authentication/authorization options are described in great detail in the Pro ASP.NET WebAPI Security book

http://www.amazon.com/Pro-ASP-NET-Web-API-Security/dp/1430257822

Even if you are not planning to build your backend around WebAPIs (but rather RESTful WCF as you mention), the book will give you necessary background on OAuth2.

On the other hand, if you still insist on WS-Federation, this free e-book describes both active and passive scenarios:

http://msdn.microsoft.com/en-us/library/ff423674.aspx