It turned out getting to know the IP address of the incoming client request to authenticate was quite difficult. Actually, the WebLogic SSPI APIs for the Authentication part did not allow us to get the IP address.
Okay, so I thought I could simply put the IP address on some thread local storage in a WebLogic ConnectionFilter implementation and then access it from the Authentication implementation. But, guess what, the ConnectionFilter implementation and the SSPI implementation for a user request does not execute on the same thread, rendering the thread local solution useless.
Hmm, what then. I - briefly - thought about creating a servlet filter that could throw off the sensitive users after authentication but before application logic. It would work, but had several drawbacks
- I - and others - would have to remember to mount the filter, and do it correctly, before any actual application logic
- The sensitive user would actually be allowed login from a non-allowed IP before being thrown off
Basically, a ContextHandler is a Map like object, which contains "context information" from the request, which can be used in the process of authorization of the given resource. When the resource is a URLResource, a HttpServletRequest can be found in the ContextHandler which makes it possible to obtain the IP address.
So, the final solution ended up checking IP address and username against known IP ranges, all at authorization time. Sadly, this is still after authentication, but we simply could find no other solution inside the WebLogic SSPI APIs.