You need the Waffle implementation of BASIC to enable actual Windows logon and get a consistent set of roles whether you authenticate via NTLM, Kerberos or Basic. I may be wrong, but all the authentication providers that I have seen don't do anything about
user Active Directory groups. You can't know, for example, that domain\user is a member of domain\group, much less nested groups.
Right, I forgot to mention that I'll also configure waffle's WindowsAuthenticationProvider in spring's AuthenticationManager. So, if Negotiate/NTLM are used, the NegotiateFilter will short-ciruit to perform the auth, but if basic auth is used, it will
fall through spring's BasicAuthenticationFilter... and then down to AuthenticationManager (which will then use the WindowsAuthenticationProvider)
The next smaller problem is that something needs to return a 401 Access Denied and challenge correctly the client in the right order (Negotiate, NTLM, Basic) and properly set connection=close/keep-alive. I couldn't achieve that without terminating the connection
in the filter and hence adding Basic auth externally was not an option. I might have been doing something wrong though.
Right, that's where spring's AuthenticationEntryPoint comes into play. I would have to write my own that would handle what I want. Waffle's NegotiateSecurityFilterEntryPoint delegates to the configured SecurityFilterProviders to provide the available
security mechanisms in the 401 response. I couldn't rely on that, since the BasicSecurityFilterProvider would not be configured. So mine would have to have knowledge of the protocols handled by waffle's SecurityFilterProviders AND by basic auth.
Right now, in my prototype, I've essentially hardcoded Negotate/NTML/Basic on windows and only Basic on unix. Off the top of my head, I can't think of an elegant way to not hardcode it.
All that aside, do consider submitting patches to Waffle instead of reimplementing a very similar filter. I am totally open to new options that make the behavior (eg. passthrough) configurable.
I'd be happy to submit patches. The really tough part is what you have mentioned regarding the 401 response with the correct headers. I'm hoping to get a prototype working with hardcoded values, then I'll try to find an elegant way of determining
the correct response. If I can do that, I'll submit a patch. Otherwise, I doubt you'd want waffle to have to rely on the user hardcoding values. We could discuss this after I get it working though.
PS: some guys at LikeWise were promising to extend waffle to use their unix-based SSP to do NTLM on *nix ;)
Oh, that would be sweet. :)
Thanks for the prompt response!