0

I have an existing WCF service that uses TransportWithMessageCredential security. It requires a username and password and uses a CustomAuthorizationPolicy and a CustomUserNameValidator. This is all configured from within the web.config in bindings / behaviors and all works fine.

However, we have a requirement to add a new method to this service specifically for a new vendor, and I'm being told this new vendor uses a Java client and will not be able to figure out how to authenticate with the credentials in the header, like is required for all the other methods in this service.

So I've been asked to simply take a username and password as arguments to the new method instead, and use those to manually authenticate against our user store in the database.

My question is, since they want this method included in the same service that requires authentication for every other method, is it possible to implement it that way so a single method is exempt from the authorization / authentication policy that all the other methods require?

Jim
  • 6,753
  • 12
  • 44
  • 72

1 Answers1

1

You could add an endpoint that doesn't use the custom validator

Justin Killen
  • 728
  • 6
  • 19
  • Wouldn't that endpoint then expose all those other pre-existing methods without requiring authorization for them? I don't think this is a viable option. – Jim Jun 30 '14 at 15:50
  • You'd need to put the altered functions into a different contract and reference that in the new endpoint – Justin Killen Jun 30 '14 at 20:38
  • Different contract = different service = not what I asked. I'd like to know if what I asked is possible. It may not be. – Jim Jul 01 '14 at 12:43
  • WCF services define custom password validations in behaviors that are applied to a service, so there is not a straight-forward way to have a single service with multiple password validation types. I'd say your best bet is either to create a java wrapper/lib for the new vendor, or create another service to act as an intermediate tier. That being said, you could (cautiously) use OperationContext.Current within the password validation code to just return true for such functions. http://stackoverflow.com/questions/852860/wcf-retrieving-methodinfo-from-operationcontext has more info. – Justin Killen Jul 01 '14 at 17:07
  • Good answer. In short, what I'm asking can't really be done. I think your suggestion of using OperationContext.Current, while it's a good thought, probably won't work because I think an exception would be thrown before getting that far if the calling client doesn't include any username / password in the header. But good answer nonetheless. Thanks. – Jim Jul 02 '14 at 00:05