and checking for client cert, if none, then require kerberos. It
seems to work.
On 6/14/24 12:28, Joakim Erdfelt wrote:
> but ssl client cert auth does not
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.