10

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.

Community
  • 1
  • 1
Sunny Milenov
  • 21,990
  • 6
  • 80
  • 106

3 Answers3

4

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.

ale
  • 519
  • 2
  • 11
  • Thanks. I was looking at similar approach - the module I was looking at is: http://www.codeproject.com/KB/aspnet/mybasicauthentication.aspx. And the same guy shows how to hook down the line: http://www.leastprivilege.com/HTTPBasicAuthenticationAgainstNonWindowsAccountsInIISASPNETPart3AddingWCFSupport.aspx. Did you go trough something similar, or you have found some shortcut to get the identity from the context? – Sunny Milenov Jul 29 '11 at 14:57
  • It's a bit different than how it is shown in the links. We were looking to 1) make the authentication piece unit testable so we had remove all dependencies to HttpContext.Current. 2) Allow for the identity to be provided by other than HttpContext.Current in the business logic because the same BL could be invoked from places other than the web service. To do this we created IdentityFactories, and when the process is running under the WS we inject a factory that looks at the HttpContext. Does that make sense? I can edit the answer with more detail later. Right now I'm in rush, hope this helps. – ale Jul 29 '11 at 17:16
  • This makes sense. My Q. was if you have intercepted in these exact places, as they show, or you have found a more appropriate way. Otherwise, you are right about the factories. – Sunny Milenov Jul 29 '11 at 19:10
  • 1
    The module intercepts at the AuthenticateRequest (similar to the CodeProject link) and passes over to our custom built authenticator. So in that sense, it is similar. Our approach has worked well for us. If you come up with something different I would like to hear how you did it. Good luck! – ale Aug 01 '11 at 14:46
0

You can create an implementation of IAuthorizationPolicy and replace the primary identity with the one you get during authentication. Have a look at these links which show how to avoid hitting database twice:

WCF Custom Validator: How to initialize a “User” object from custom validator

When and where to set custom IIdentity when implementing custom authentication

Community
  • 1
  • 1
Giorgi
  • 30,270
  • 13
  • 89
  • 125
  • I have read, and keep reading and rereading all these articles, but looks like everybody at the end gets confused, and usually decide to go other way. I'll edit my question with more details, but still I have no solution to my problem. – Sunny Milenov Jul 29 '11 at 13:49
0

I ended up not using WCF at all. Nancy was much easier to create and test RESTFull API, and with the latest changes (it'll be in 0.8 ver) what I was asking about is very easy.

Sunny Milenov
  • 21,990
  • 6
  • 80
  • 106