You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2016/06/24 05:49:38 UTC

[Bug 59750] New: Amend "authenticate" method with context by means of HttpServletRequest

https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

            Bug ID: 59750
           Summary: Amend "authenticate" method with context by means of
                    HttpServletRequest
           Product: Tomcat 9
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: hauser@acm.org

Principal org.apache.catalina.Realm.authenticate(String username, String
credentials) and the other authentication methods should be enhanced with the
request.

Purpose: during an authentication, it should be possible in a webApp-level log
to record important details such as 
- remote IP
- SSL cipher
- client cert used (if applicable)

At least interface Authenticator.authenticate() and

   boolean
org.apache.catalina.authenticator.AuthenticatorBase.authenticate(Request
request, HttpServletResponse response) throws IOException

have everything needed.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by Mark Thomas <ma...@apache.org>.
On 06/06/2019 20:06, bugzilla@apache.org wrote:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59750
> 
> --- Comment #14 from jerry <je...@gmail.com> ---

I've disabled this idiot's account.

I'll delete the comment from the database shortly.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #14 from jerry <je...@gmail.com> ---
Technical side of the main subject. For example Tomcat F14 Fighter Jet.
The specification of a Tomcat will be a good reference.
The complication of the machine and material. 
Will come in handle for us to digest in the long run.
Project basic Etc
In term of troubleshooting And Upgrading.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #1 from Christopher Schultz <ch...@christopherschultz.net> ---
What about a listener for authentication events?

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #6 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Michael Osipov from comment #5)
> GSSName or X509Certificate and like. I always prefer passing Object and the
> implementation decides about the cast.

Seems reasonable.

Tomcat only supports authentication for string usernames or X509 certificates
(where the "username" is extracted as a String value from the certificate via a
X509UsernameRetriever). Do you still feel there is a need for the
user-identifier to be a generic Object?

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #11 from Mark Thomas <ma...@apache.org> ---
JASPIC exposes both the request and the response. The solution to this one
could just be "Use JASPIC".

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #2 from Christopher Schultz <ch...@christopherschultz.net> ---
Created attachment 35824
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=35824&action=edit
Draft patch to give an idea of the proposal

See this draft patch for something that might work. At least, it will meet *my*
needs. There is no provision for registering these listeners. It's just an
example of how this kind of thing could work with FormAuthenticator as the
guinea pig class.

Comments welcome.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #8 from Christopher Schultz <ch...@christopherschultz.net> ---
Two additional thoughts:

1. Could this be implemented as a Realm which can wrap another realm? This may
simplify things when a user wants to authenticate using one-of-many concrete
realm implementations.

2. Does JASPIC provide anything like this already, or specify any interfaces,
etc. for this kind of thing?

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #10 from Remy Maucherat <re...@apache.org> ---
I agree you could experiment with a combined realm (lockout realm is an example
of that indeed), it would need to call your listener in authenticate and
invoke.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #9 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Christopher Schultz from comment #8)
> Two additional thoughts:
> 
> 1. Could this be implemented as a Realm which can wrap another realm? This
> may simplify things when a user wants to authenticate using one-of-many
> concrete realm implementations.

Justification for Realm over Authenticator:

1. Realm is easier to configure for users than authenticator(s)
2. Realm is more flexible since they can be nested ; you can track failures of
specific realms separately from one another
3. Custom authenticators do not need to be re-written to use this new
capability

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #7 from Michael Osipov <19...@gmx.net> ---
(In reply to Christopher Schultz from comment #6)
> (In reply to Michael Osipov from comment #5)
> > GSSName or X509Certificate and like. I always prefer passing Object and the
> > implementation decides about the cast.
> 
> Seems reasonable.
> 
> Tomcat only supports authentication for string usernames or X509
> certificates (where the "username" is extracted as a String value from the
> certificate via a X509UsernameRetriever). Do you still feel there is a need
> for the user-identifier to be a generic Object?

I would always retain as much information as possible. Regaining it is
impossible afterwards.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #13 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Mark Thomas from comment #11)
> JASPIC exposes both the request and the response. The solution to this one
> could just be "Use JASPIC".

Sounds great. Now how does one "use JASPIC" to use a simple DataSource for
authentication? If someone who understands JASPIC could do a write-up on how to
configure (or code) against a standard username/hashed-password database table,
that would be very helpful.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #3 from Michael Osipov <19...@gmx.net> ---
(In reply to Christopher Schultz from comment #2)
> Created attachment 35824 [details]
> Draft patch to give an idea of the proposal
> 
> See this draft patch for something that might work. At least, it will meet
> *my* needs. There is no provision for registering these listeners. It's just
> an example of how this kind of thing could work with FormAuthenticator as
> the guinea pig class.
> 
> Comments welcome.

This applies to FormAuthenticator only? The API isn't generic enough. Don't
assume the username to be a string only.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #5 from Michael Osipov <19...@gmx.net> ---
(In reply to Christopher Schultz from comment #4)
> (In reply to Michael Osipov from comment #3)
> > (In reply to Christopher Schultz from comment #2)
> > > Created attachment 35824 [details]
> > > Draft patch to give an idea of the proposal
> > > 
> > > See this draft patch for something that might work. At least, it will meet
> > > *my* needs. There is no provision for registering these listeners. It's just
> > > an example of how this kind of thing could work with FormAuthenticator as
> > > the guinea pig class.
> > > 
> > > Comments welcome.
> > 
> > This applies to FormAuthenticator only? The API isn't generic enough. Don't
> > assume the username to be a string only.
> 
> This was a proof of concept, to get feedback. Can you suggest a username
> that cannot be represented as a string?

GSSName or X509Certificate and like. I always prefer passing Object and the
implementation decides about the cast.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #12 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Christopher Schultz from comment #9)
> Justification for Realm over Authenticator:

Justification for not using Realm:

1. No access to HttpServletRequest (for e.g. IP logging)

:(

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 59750] Amend "authenticate" method with context by means of HttpServletRequest

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

--- Comment #4 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Michael Osipov from comment #3)
> (In reply to Christopher Schultz from comment #2)
> > Created attachment 35824 [details]
> > Draft patch to give an idea of the proposal
> > 
> > See this draft patch for something that might work. At least, it will meet
> > *my* needs. There is no provision for registering these listeners. It's just
> > an example of how this kind of thing could work with FormAuthenticator as
> > the guinea pig class.
> > 
> > Comments welcome.
> 
> This applies to FormAuthenticator only? The API isn't generic enough. Don't
> assume the username to be a string only.

This was a proof of concept, to get feedback. Can you suggest a username that
cannot be represented as a string?

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org