UserNamePasswordValidator

Question

I am validating users using the UserNamePasswordValidator.Validate(string username, string password) and the service is hosting itself (e.g. no IIS).

The problem I have is that if the user fails the validation I want to track the users IP address. This works fine of the user gets validated, because then the OperationContext has been initialized (it is null inside the validate method and not created until later).

Does anyone know how to get the clients IP address either in the validate method or before the validate method has been executed?

Yes, I know about how to get the IP address using RemoteEndpointMessageProperty but like I said, it never get that far if validation fails :-)

Answer 1

I've researched this to death all week, and I can't come up with a single blog entry or MSDN article that deals with the issue.

As far as I can tell, you cannot log IP address during the Validate stage.

The only workaround I can suggest is to host in IIS and use the weblogs there, which do log IP address. It's painful, unfortunately, but it may be the only way.

Answer 2

If you're hosting in IIS then this becomes much more simple. This chunk of config comes straight from my hosting web project and forces ASP.NET requests to come down the IIS pipeline rather than being dispatched straight to the ASP err bits of IIS.

aspNetCompatibilityEnabled: When this attribute is set to true, requests to Windows Communication Foundation (WCF) services flow through the ASP.NET HTTP pipeline, and communication over non-HTTP protocols is prohibited.

See: http://msdn.microsoft.com/en-us/library/ms731336.aspx

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

I use the AuthenticationService and make use of the HttpContext to get at all the interesting stuff about the client, much of it is useful for things like ensuring a user isn't logging in from six different subnets as well as playing around with cookies.

Although I think this is applied to the MS AuthenticationService, any other services you have will need this attrib:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

If you want to pursue your non-IIS hosted service route, then I'd see what stuff is available inside the MS API using reflection, poking around on a WCF with the debugger while stopped, unfolding all those Non-public members.

I suppose the problem will be getting a reference to a bit of WCF which is initialized from which to start poking. You might have to register some kind of listener to one of the dispatchers when you setup the service host.

http://msdn.microsoft.com/en-us/library/system.servicemodel.dispatcher.channeldispatcher.aspx

Edit:

Adding this link as my thoughts are that you'd need to get at stuff in WCF that's right down the stack before it gets to your code:

http://blogs.msdn.com/sonuarora/archive/2007/06/11/passing-soap-actions-to-adapter-inbound-handler-for-filtering-type-of-listeners.aspx