Hello Christopher, Some very good feedback here. Thank you.
The web server in question doesn't need to authenticate any users at all. But, as a part of the SSO handoff, the web server in question is being passed Basic Auth in the header. Any further authentication (e.g. the examination of the header) is handled by the application. So, with regard to the web server in question, how to ignore the Basic Auth? Tony -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, October 12, 2018 3:07 PM To: users@tomcat.apache.org Subject: Re: Tomcat 8 and authenticating Basic Auth users -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tony, On 10/12/18 15:41, Tony Esposito wrote: > Concerning tomcat-user.xml versus database: The number of users has > increased by an order of 2 magnitudes AND we don't know ahead of time > who those users will be. The user count is an estimate of the number > of companies (known) multiplied by the number of users at each company > (unknown - we know it is greater than 1). Uhh... you need to authenticate users but you don't know who they are? This sounds like either you don't need authentication or you are doing something very dangerous. Perhaps you are trying to solve Y but you are asking about X. What is Y? What is the use-case, here? What are you protecting? Why do you need authentication? How are you expected to do it without being able to identify users? This seems like a good case for using CLIENT-CERT authentication where you trust each company's root cert and each employee at that company gets their cert issued by their company. There are problems with CLIENT-CERT authentication (like revocation is a PITA) but at least it fits the use-case better. Another option would be to tie-into each company's LDAP server. Then, they can use their own username+password just like they use for other services. Or, if you don't or can't implement the above, use something like SAML/OAuth to transfer a user from one trusted system (like a client company's system) into your own. You can request specific user information be set to you as a part of that SSO handoff and you can "register" them "locally" so you'll recognize them the next time they authenticate. > Concerning Basic Auth: > > Users are already signed on via SSO thru another application. And > they cannot login directly to this application. A header is passed to > my web app which has the static password (so I can't do much about > that). (Yes, bad...bad...). Unfortunately, the header also has Basic > Auth passed to my application. You can always ignore that header. > I need Tomcat to pass this request on through, ignoring the Basic Auth > in the header. No problem: just remove all authentication and authorization configuration from web.xml and Tomcat will happily pass those headers to your application without doing anything to them. Tomcat will also happily pass that information to your application even if those headers are being used for authentication and authorization. - -chris > -----Original Message----- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Friday, October 12, > 2018 2:25 PM To: users@tomcat.apache.org Subject: Re: Tomcat 8 and > authenticating Basic Auth users > > Tony, > > On 10/12/18 14:45, Tony Esposito wrote: >> Thank you André for this feedback. > >> If I may, I wish to approach this from another angle. (The user >> community is larger than at first anticipated). > > Since you are switching away from tomcat-users.xml to a real data > store, why does a larger user community change things further? > >> If the header received has a certain password (which is static for >> all users requesting access), then bypass Basic Auth and let the user >> connect. > >> (The application does more security checking and authentication on >> the header.) > >> So the question becomes: > >> How to disable Basic Auth when the header contains a password which >> is static for all users requesting access? > This make zero sense. > > HTTP Basic authentication will require the user to enter their > credentials. Once they enter their credentials, you'll inspect the > password for some magic value and then you want to retroactively > DISABLE HTTP Basic auth? I believe that requires timey-wimeyness. > > Why not simply always require username+password, and then > opportunistically perform additional checks (as mentioned, but not > described) above? Once the user has authenticated successfully, the > browser will continue to send the username+password with each > successive request and the user won't be asked again for their > credentials. > > The definition of "authenticated successfully" from the browser's view > is when the server stops sending the "WWW-Authenticate" > response header. > > BTW static password == bad bad bad bad bad bad bad bad bad > > If you have a static password, why bother asking for it in the first > place? It's like requiring a username + password for a terminal and > then stamping the username and password on the monitor. You may as > well remove the challenge. > > -chris > >> -----Original Message----- From: André Warnier (tomcat) >> [mailto:a...@ice-sa.com] Sent: Friday, October 12, 2018 11:29 AM >> To: users@tomcat.apache.org Subject: Re: Tomcat 8 and authenticating >> Basic Auth users > >> Hi. > >> On 12.10.2018 16:38, Tony Esposito wrote: >>> Hello, Using Tomcat 8.0.22 on Linux CentOS 6.10: >>> >>> Trying to setup Tomcat to authenticate users that use Basic Auth. I >>> could (possibly) enter these users into the tomcat-users.xml file >>> but we are dealing with 1000 potential users. >>> >>> What happens instead is (of course) the users fail to authenticate >>> and then subsequent attempts by the same user locks the user's >>> account. >>> >>> 11-Oct-2018 16:21:37.970 WARNING [http-nio-8088-exec-25] >>> org.apache.catalina.realm.LockOutRealm.authenticate An attempt was >>> made to authenticate the locked user "myuser" >>> >>> This is 'normal' since after a failed attempt to log in, Tomcat >>> suspects a 'brute force attack' and locks the account. I don't want >>> to lose that security but (as mentioned above) I can't just enter >>> all users into the tomcat-users.xml file >>> >>> So the basic question: How to do authentication of 1000 >>> users that use Basic Auth? >>> >>> Thanks. >>> >>> Tony >>> >>> > >> There are two separate parts to this (and it is not specific to >> Tomcat) : > >> - the "basic auth" part, is the way it talks to the browser, to get a >> userid/pw (in this case, through a browser popup dialog) > >> - the "realm", is the way that the server *verifies* the user-id/pw, >> with some back-end "authority". In your case, you have specified that >> this realm is a file. But it can be something else, like a database. > >> The two are independent, and you can mix and match according to your >> needs. The on-line Tomcat documentation helps, see : >> http://tomcat.apache.org/tomcat-8.5-doc/realm-howto.html > > > > > >> --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > >> --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvA/uQACgkQHPApP6U8 pFiAzhAAiJCdFPcK+I4triDfToJ7AzjAC2LpOh6Q4C73s5t8+w+EHgXC1Biu1M0J HnDIl57X4uP1PjwzesHQT8ITd82HvMv7TC66+vH58/Z6F0r3cHVzHfT2welohWCG pgHVWo/Kd7Mmzb/WfqCNrtEH3VjQSFKqm8bferLj4qIorT7W4/XCfFGqC6jcHU/8 BMhXksSB2miFMxXomx33cYDKO+0bef3Vj+UDvyqklyZbVIIYn4tGPzLREyHaOkh8 Um0bp+Cm9R1GFRsNupWQ8DzDTQFUlG/yY+a00VxmqP/t6Y7X9Gb/weXJSUv4G7/e QKZqSJVhgyawZML1guxQ/AoZVLdBMGzabS7WShQDcAO8a+9JfIAZiHa3lCegNzld YHOXicBwV9jEL9pttGRRWfQhgjEAU8gSOgtV/TSUYo8j5T2kxDQqH3m2JIWayiU8 8DSow5Nj4tqG1FTtn81JiHp0w2GdRwM6eQmTlnRRZUUStM0UbtcDDagZDBjRG0Xn teI5lZn1JOswVoYJAQu95arb8uWGdTPmdLKnMfE6xodJgdwFzT8ewknWQSh2OPT7 vjLZBpGrpiiz8d9wQfsvE+bHB68rJoUngtd3KegpEzxZ5/wKy0BtLJZx8laZH8gP sKgZFoIILHiNNv58ly6x+r6yYLt2xaFGDy/HjML58E2mI2JqkD8= =EwWR -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
