Be careful here, as SSL Client Cert occurs deep in the bowels of the Java SSL implementation itself, and Jetty is not involved in that.
The Java SSL implementation will either allow through, or reject the incoming connection based on the SSL Client Cert.
If it is a good client cert, you have a connection, otherwise if the client cert isn't good you do not have a connection (and also have no request, or handling of that request).
- Joakim
On Fri, Jun 14, 2024 at 7:12 AM Jeremy Jackson via jetty-users <jetty-users@xxxxxxxxxxx> wrote:
Hi Jan,
Thanks for the reply... I was starting to drown in source code
when I got your message, which helped immensely.
What I am doing is creating a virtual thread for each session,
after authentication succeeds. I wanted to use the Listener to
create the thread, but can't seem to get the authentication info
in that context.
What I have found ( in Jetty source code ) is that the Session
Lifecycle Listener(s) are fired synchronously when
getSession(true) is called, (which SPNEGO authenticator does, but
ssl client cert auth does not) and so the Principal which is added
to the Session right after, is not accessible to the Listeners.
A workaround I came up with is to put all my code into one
monolithic Handler after SessionHandler (it's a separate auth and
thread-launcher handler now, with session in the middle):
if (request.getSession(false) == false) {
auth (client cert or kerberos)
getSession(true)
launch thread with user_id info
}
I will look at the SecurityHandler but the SPNEGO authenticator
which calls getSession(true) would break this arrangement.
On 6/14/24 00:10, Jan Bartel via
jetty-users wrote:
Jeremy,
The SessionHandler is the handler that resolves any
existing session when a request enters a context, so it needs
to be before anything that might access a session. By merely
putting the SessionHandler first, you aren't guaranteeing that
a session will always be created - this only happens iff it is
either programmatically requested, or you hit a url with a
security constraint on it that means that a FormAuthenticator
- or other custom type of Authenticator - is invoked and it
creates a session. Are you sure you don't want to extend
SecurityHandler?
Jan
On Fri, 14 Jun 2024 at 01:23,
Jeremy Jackson via jetty-users <jetty-users@xxxxxxxxxxx>
wrote:
Hi,
I'm working with Jetty 12 trying to put a Kerberos and Client
Certificate authentication handler *before* Jetty's default
SessionHandler, and I'm coming up short on a way to propagate
the authenticated identity into the HTTP Session.
specifically, I would like to access the Session from the
onSessionCreated() method. I'm open to extending one of
Jetty's session components (as suggested by chatGPT) but I
thought I'd inquire here first.
This is a Jetty embedded, native API project.
The examples I have found all have the SessionHandler coming
first, so any subsequent handlers would have access to the
Session, however I want to avoid creating a session entirely,
for unauthenticated connections.