WCF Basic Authentication and custom token authentication

Question

Hi,

I've got a RESTful WCF service using Basic authentication, a custom service host, and a . I've got a custom UserNamePasswordValidator set up, and a custom IPrincipal correctly flows through to the operation. For legacy interoperability, I need to support a different mode of authentication, however. The way it should work goes:

1. User POSTs to a login URI
2. The service authenticates the user as above, but returns a session token (encrypted user credentials) as an HTTP response header.
3. All subsequent requests from the user contain the session token instead of Basic authentication.

My current thought is this: if the session token contains encrypted credentials, then it should be possible to manipulate the incoming message, decrypting the credentials and replacing the session header with a Basic authentication header. My problem is finding an extensibility point that:

• Exposes the message properties in some way AND
• Is executed -before- the custom UserNamePasswordValidator executes..

Do any of you gurus know of such an extensibility point, or a way to customize the transport security mechanism? I'm honestly bewildered by the vast array of options here, and browsing the System.ServiceModel namespaces in Reflector has been an exercise in frustration.

Thanks!

Answer 1

I discovered the answer on my own, and the answer is that I couldn't figure out how to implement the exact mechanism outlined in the question - namely replacing an HTTP header with another before password validation.

Instead, I replaced the UserNamePasswordValidator with an IAuthorizationPolicy. Inside the policy's Evaluate method, another class handles checking for either Basic credentials or a session key, and returns the custom IIdentity. The key here is that, on a successful authentication, a new List containing the custom ID is added to the "Identities" property of the evaulationContext, and the custom principal is added to the "Principal" property. Once these properties are set, WCF correctly flows the principal through to the operation.

This has proven to be a satisfactory solution, but I'm still disappointed not to have found the extensibility point I was looking for.