Token-Based Authentication in WCF

Question

I am creating a website which will contain both ASP.NET pages and a Flash applet. I want to encapsulate my business logic in a WCF service which will be exposed through two endpoints: One accesssible over the Internet through HTTP(S), for use by the Flash client, and one accessible within the data center for use by the application servers. If this does not seem like a good approach, then stop me here; otherwise, I'll move on...

The question is how to authenticate requests coming from the Flash client. Since I don't want to store the user's password in a browser cookie, don't want to send the password with every request, and don't want to have to use HTTPS after the initial login, I plan on using a token-based authentication system. I also don't want the user to have to log into the Flash client after already logging into the site itself, so I plan on using Javascript to pass the token to the Flash client when it starts.

I know WCF supports using the .NET Framework's built-in security framework (System.Security) to enforce access control, and I would like to take advantage of this.

The question, then, is: How do I pass the token to the WCF service when it is called by Flash, and how do I process the token on the server?

• WCF has an "issued token" authentication mode, but it appears this is intended to be used in a full-blown federation scenario with a Secure Token Service and SAML tokens--a bit more complexity that I really want. It is possible to use this mode with my own "simple random-string" tokens? If so, how? Keep in mind this needs to be compatible with Flash.
• I could potentially pass the token in a header (either a SOAP header or an HTTP header). In this case, once I've determined which user is making the request, how do I inform the framework so that the System.Security checks will work?
• Is there a different approach altogether that I should consider? Anything that avoids sending passwords in every request, lets me use System.Security, and works with Flash is a possibility.

Answer 1

As it seems the original question has been answered I'll keep this brief, but one approach would indeed be to pass the authentication token in an http header and override CheckAccess(OperationContext operationContext, ref Message message) in a custom ServiceAuthorizationManager .

You will have previously configured the service to use a custom policy that implements IAuthorizationPolicy.

All that remains is to implement simple IIdentity and IPrincipal classes to store your authorization state.

A number of good articles exist on this subject:

http://msdn.microsoft.com/en-us/library/system.identitymodel.policy.iauthorizationpolicy.aspx

http://msdn.microsoft.com/en-us/library/system.servicemodel.serviceauthorizationmanager.aspx

I guess this may still feel like a "roll-your-own" solution, but its at least reassuring when you're following an established pattern. It does have the advantage of black-boxing your authorization code from your service methods.