Werner,
On 10/15/21 09:10, Werner Dähn wrote:
Thanks Mark. Why do you believe the refactoring is difficult? All we
actually need is access to the response object.
... which requires a lot of refactoring. Have a look at all the code
that handles authentication in Tomcat.
This would allow to add session data, URL parameters, whatever. And
this response object is available everywhere except in the actual
RealmBase. By my analysis the change would be rather simple and
provide a feedback channel. If that feedback channel is used and for
what, is a separate discussion and decided by the real implementer.
What you really want is the request object, not the response. You can't
set attributes on the response, but the request has that, plus it has
all kinds of other juicy information such as the user's IP address (to
be used for per-user IP-based access-checks), secondary authentication
information in the form of (previously-set) request attributes and/or
request parameters.
I'm 100% in favor of adding the request to the whole authentication
ecosystem. Correct me if I'm wrong, markt, but I think the whole idea of
JASPIC was to allow essentially arbitrary, pluggable front-ends *and*
back-ends into the authentication system. If that's the case, I'd love
to know how to take a vanilla FORM username+password configuration using
FormAuthenticator + DataSourceRealm and make it work using whatever
JASPIC magic needs to be configured just to do the same work.
Presumably, it's not terribly difficult from there to introduce things
like "also pass the request" through all that from front-end to back-end.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65635
-chris
On Fri, Oct 15, 2021 at 2:01 PM Mark Thomas <ma...@apache.org> wrote:
On 15/10/2021 07:05, Werner Dähn wrote:
<snip/>
So why has this not been done? What am I missing?
Accepted security good practice is not to provide any information to a
user as to the reason for a failed authentication. The idea is that it
could help an attacker by, for example, letting them know they have a
valid user name but an invalid password.
I'm not entirely convinced by the arguments used to support the above
position. They generally seem to be based on the assumption that a brute
force attack is possible. I'd argue that any system susceptible to a
brute force attack has problems irrespective of whether it provides
feedback on authentication failures.
I do think there is an argument to be made that trading reduced
usability (no feedback on authentication failures) for allegedly better
security (brute force attacks are harder) is not a sensible trade-off.
That said, I appear to be in the minority. Again.
Does an enhancement request exist??
No.
I do think there is an argument for providing information on the reason
for the authentication failure via a mechanism that allows system
administrators to decide if they want to pass it on to the users or not.
Something like a request attribute that could be included in a custom
error page for example.
However, the current Tomcat code for authentication is structured in
such a way that exposing the reason for an authentication failure would
require a reasonable amount of refactoring. I don't think an enhancement
request along these lines will be rejected, but neither do I think it
will be implemented quickly. I'd expect a fair amount of discussion
about how to refactor the Realm interface to expose this information.
Mark
---------------------------------------------------------------------
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
