Here is a little adventure we ran into using WCF. We are using the CustomUserNameValidator and allthough it’s so fun to use, it’s got a few nasty problems…
4 Easy steps to implement into your project:
- Create a classe that derives from UserNamePasswordValidator
- Override the Validate method, this method receives the username and password as parameters
- Throw an exception if the username and password are invalid
- Hook it up to your service using configuration
Now for the nasty stuff:
- All you receive is the username and password, nothing else (like the ip of the caller, a session id or message id…) because OperationContext is null
- No way to send information forward to the service (for exemple the time it took to perform the authentication). This was actually problematic for us so we had to store the time it took to authenticate by username, then later on try to fetch an the data and add it to the service time. You do have the problem that you might grab the wrong authentication information for a given service call but unless you are in a highly parallel environment, it kind of works. You also have to think of performing cleanup on this cache so that memory doesn’t leak. Last gotcha is that if you are using a sessionfull endpoint, only the first service call gets an authentication (which is kind of true, being there is a session).
- We found a nasty bug where authentication occurs sequentially, even if our endpoint is equipped for parallelism, which creates a problem because authentication in our case takes around 50ms. If we just return from the validator, we can see the service working in parallel, but since our authentication code is longer than the actual service code’s execution, we see very boring results which look like queuing. We are using an http2007Binding over SSL with no Secure Conversation Token and custom username password authentication.
The bug has been logged with Microsoft, and i hope they give us a good news quicky, through a patch and a switch to be able to turn on the feature…