How to configure waffle.servlet.spi.BasicSecurityFilterProvider

Dec 17, 2010 at 12:05 PM


I am using Waffle Servlet Negotiate Security Filter. What do I have to configure in Tomcat for waffle.servlet.spi.BasicSecurityFilterProvider init parameter? My goal is, in the case that negotiate authentification failed, that the user with a username from tomcat-users.xml will be accepted (with the windows authentification dialog).

And another question: is it planned in waffle to allow more than one domain, so that users from different domains can be authentificated?

Thanks for a help.

Dec 17, 2010 at 1:08 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Dec 17, 2010 at 1:10 PM

The BasicSecurityFilterProvider doesn't check withthe tomcat's users.xml, it still checks with Active Directory. So you would need to use or write something else to do that kind of fallback. That's a valid feature request and could be generally useful in scenarios where Active Directory is unavailable, misconfigured, etc. - if you implemented something like this I'd take a patch for Waffle.

For the second question. Waffle uses Windows SSPI, so if your machine is a member of a domain that trusts another domain you can login with a user from the trusted domain. That's in general, specifically it may be more complicated depending on how the Active Directory trusts are setup. Regardless, this is completely automatic and works exactly like any other Windows logon.

Dec 20, 2010 at 12:51 PM


thank you for your reply. My second question is fully answered.

But concerning the first qustion I don't undestand, what the BasicSecurityFilterProvider does? Where and how I need to configure a realm?
There is WaffleFilterDemo as param-value for BasicSecurityFilterProvider in Waffle Security Filter Demo defined. But there isn't realm with this name.  Or should I take the defined realms of Tomcat as <param-value>, for example UserDatabaseRealm?


Thanks for your help.

Dec 20, 2010 at 1:21 PM
Edited Dec 20, 2010 at 1:23 PM

You're confusing two things: realms and filters don't mix.

  • Filters are something from a servlet specification, which Tomcat implements.
  • Valves and realms are something from the Tomcat proprietary mechanisms.

The BasicSecurityFilterProvider serves clients that don't understand Negotiate. The server tells the client: you got three options: Negotiate (NTLM or Kerberos, please pick), NTLM or BASIC. The client chooses what to use. In the case of the first two (95% of clients) you never get a username/password on the server, even if you saw a popup on the client (the client calls LogonUser with the creds you entered then sends a Negotiate toke to the server). And only with the BASIC auth you get a username and a password, which is then checked against Windows SSPI (Local, Active Directory, etc.) by calling the Windows LogonUser API on the server. You could swap the latter BasicSecurityFilterProvider for whatever, but that won't work with any modern client that will persistently pick Negotiate.

To summarize, what you want to do is fallback to a local file when Negotiate or NTLM failed, not when the client chose to use BASIC auth. You want the client to send you a username/password in that case. The only viable strategy IMHO is to do what MixedAuthenticator does. The user has to choose what to do BEFORE any authentication is done. In the MixedAuthenticator example a user lands on an unprotected page that lets him choose which mode of authentication to use (Forms or Negotiate). Then the POST url contains different parameters that help the filter distinguish what to do. If it's forms auth, we call LogonUser. If it's negotiate, we do the NTLM handshake. You can basically create a link or a button on that page that tells the filter not to do Negotiate or LogonUser, but to check against a user database (call it admin logon).


Dec 21, 2010 at 7:53 AM

Thanks for your help and recommendation. I will try the MixedAuthenticator.