On 13.10.2018 00:04, Tony Esposito wrote:
Addendum:
The user "myuser" attempts to authenticate once, fails, and on the second
attempt the WARNING is thrown (i.e. user locked) which is to be expected.
I want the user "myuser" not to authenticate at all by having the Tomcat
instance 'ignore/bypass' the Basic Auth (that is received in the header).
But you still want your application to see this Basic Auth header, because it needs to
check the "standard password" in it, right ?
(Otherwise, describe precisely what you want).
P.S.
1) You say "Installed 'out of the box - as is'", but what box ?
The standard Tomcats 8.0 or 8.5 do not have an active Connector for port 8088.
So it does not look as if it is so 'out of the box - as is'.
Where does that Tomcat come from, really ?
2) your application has a WEB-INF/web.xml file in it.
What does it say about authentication ?
Tony
-----Original Message-----
From: Tony Esposito
Sent: Friday, October 12, 2018 4:42 PM
To: Tomcat Users List <users@tomcat.apache.org>
Cc: Tony Esposito <tony.espos...@region10.org>
Subject: RE: Tomcat 8 and authenticating Basic Auth users
Hi Christopher,
The 'web server in question' is the Tomcat web server that I am trying
to get to ignore Basic Auth.
Installed 'out of the box - as is', this Tomcat web server instance
throws the error
WARNING [http-nio-8088-exec-25]
org.apache.catalina.realm.LockOutRealm.authenticate An attempt was made to authenticate
the locked user "myuser"
whenever a user (who has SSO'd successfully) tries to reach the web app
that runs on that Tomcat web server.
Tony
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, October 12, 2018 3:33 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 16:24, Tony Esposito wrote:
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?
What is "the web server in question"? Most web servers will ignore
authentication headers unless they have been specifically configured to do something with
it. You shouldn't have to do anything specific to get the web server to ignore those
headers.
- -chris
-----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
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
---------------------------------------------------------------------
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/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvBBREACgkQHPApP6U8
pFgzNg/+I4ervsW1nqgvLPhTZfsmrXnnegml7gOvs3e4W2RxYTMupOA+uDs0zX9D
LY7oHDKQsWDFsu0V+UUDGC5kMIDcv2rYiLoSDxVWeq01IvtMLAepZL0hAF1HGl1f
yc5CZnljXSQln+heOabULBsoWXAXSXRgXBUw5f0QbTOo5QNzVAmwNTqpHmmWvmcA
kCMwyGLbDu9uHfSvU5QaH8NEQeoLHhWUSoiVUtBzaEJyd5q5l20n+E+EGxlJL1/I
N4gSVbaJoqR2pah/MTxopbJCbJFbJCSwiurgdkxL5kt7PnubADBm+oxSP4Emgx1g
vZRuKtinAmCmJ15j5ORj/+EiIsCy58k+TVFByV78C0/pcL2v3FQTiG/HAPVugg3d
TXayWU2IQHgstZX9s0j4cEOt8RyLUrCtfRwWnJHsyKfU4hkW/A++tsu+IQRSmbgH
Pc3q8B/VtQ4iWSfB9hyEH0dTl0+W8dORmdEJfPXzOpQLyjhIZgBof4tB4HYQe18b
8WNRFV7JbQ5kismfGXmixc9TrA4UiAnxP2zNjFLIyWF7sLcdgMMy4Wmhzz8aZR47
y2EYrrU3L5LdMSFLs+qLrBPIMGDGmMo2AVNRSP7ZJv1I/poYFI+IpU7spuobSKOq
6HWC5TmDF6sfbGb7cQLE8JgizxdqJR1i66pKz+uqXBk8haPG2Bw=
=99Rw
-----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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
