The requirements:
WCF 4.0
IIS host
Basic authentication with custom source
RESTful
There are plenty of examples and ways how to implement the basic authentication, from using UserNamePasswordValidator, trough ServiceAuthorizationManager and IDispatchMessageInspector, etc.
The problem I’m facing is, that the validation actually will fetch much more information from the authentication backend, than yes/no answer. And I want to pass this information somehow to the invoked service methods (i.e. it’ll be full blown User object, with many properties to control the service behavior). I want to avoid a second call to the user store to retrieve the data based on the username, which I can access from the security context.
So far, the closest thing I found is this solution, which uses the WCF REST Starter Kit‘s RequestInterceptor, in which I can inject a subclass of ServiceSecurityContext to carry on my data, and cast ServiceSecurityContext.Current back in the service method.
The problem with the above is, that it’s written for WCF 3.5, and that I would like to avoid using the Starter Kit.
The question: any idea what would be the most appropriate place to hook into in the chain, so I can pass a data from the validation logic to the service. Or to put it another way, where I would be able to replace the security context with my custom one to carry on the load? Or any other carrier mechanism?
What I’m after is that behavior:
Client (could be a browser) tries to use the service: GET https://myservcer/service/data
The server responds with “Basic Authentication Needed”
The client supplies Basic Authentication Header and sends the request again
The server, based on the user/pass in the header, pulls out a User object out of database.
If the user is not found, request authentication again
If the user is found, the User object is somehow passed the service method
All this should happen without making second roundtrip to the database
So far, what I understand is, that UserNamePasswordValidator will not do – there’s no way to pass the User object if I retrieve it there.
I can create a custom IAuthorizationPolicy or SecurityToken (which one), and put the User object in. But … where this should happen. Can I go with UserNameSecurityTokenAuthenticator for this? Is it going to return the right HTTP error code to ask for credentials? How/where I modify the web.config to use my custom stuff? So far I see how set to use a custom UserNamePasswordAuthenticator only.
EDIT: pls check my own answer for my approach. Nevertheless the question was good, and the answers I got were valuable.
We implemented our own authentication HTTP module. The module hooks into the “on request authenticate” event of the HttpApplication and runs the authentication against the backend. The backend is free to return anything it wants (and in our case it returns more than yes/no. The object that gets returned implements the System.Security.Principal.IIdentity interface. Once the authentication succeeds we attach the identity (object returned by auth) to the principal that gets carried in the HttpContext.User.
Down the pipeline you can access the current context’s User at any point and get all of your identity’s info.
The only significant drawback of this approach is that it requires ASP.net compatibility, but if you are already running your Rest services like that then it shouldn’t be a problem.