Open fgolzari opened 4 months ago
There are many many ways this can be done, all very much dependent on details of your deployment.
But in short, an authenticator needs to be server class path. This can be done by enabling the ext module and putting a jar with your authenticator in the lib/ext directory. Or you can create your own module.
Then again hard to answer your questions exactly, but yes typically you would use something like a context.xml file to configure the authenticator on the context itself. However, init params from servlets/filters will not be available at that stage. Typically we'd put such configuration in start properties managed by a module, and set in a generated ini file, so they are available in the context.xml. These properties could then also be echoed by the context.xml as context init params, so servlets/filters could find the values.
@gregw Thankyou so much for your answer.
1- Is it possible in Jetty to create a class in the same project war file without defining a customized module and identify that class to Jetty?
2- According to your guidance in my previous question, I changed the code I had written using filters and wrote it with authenticators. My question is that in our web.xml settings, we had specified <url-pattern>/spnego/*</url-pattern>
for this filter. Is it possible to set a url-pattern
for authenticators too?
@joakime
@gregw @joakime I am still waiting for your guidance :)
@fgolzari patterns are not set for authenticators. Rather constraints that require authentication are set at patterns. Please look the org.eclipse.jetty.client.util.SPNEGOAuthenticationTest for an example.
With regards to creating a new class. You cannot create a new class in the org.eclipse.jetty.security.authentication
package/jar, unless you are prepared to fork the entire jetty project and build your own jetty. Other than that, you extended authenticator must be on the server classpath and as I said, there are numerous ways to achieve that, with a custom module being the most standard way, but not the only way.
Why do you need to extend the standard SPNEGO Athenticator? If it is a feature that others might find useful, you could always modify the jetty class and submit a Pull Request which we could consider for inclusion in the next release of jetty.
Jetty Version jetty-12
Jetty Environment ee10
Java Version 21
Question In transition from Jetty 9 to Jetty 12, We needed to customize
validateRequest()
method fromorg.eclipse.jetty.security.authentication.SPNEGOAuthenticator
class. For this purpose, I created a class in my project that extendsSPNEGOAuthenticator
class and override thatvalidateRequest()
method.SPNEGOAuthenticator class is part of Jetty's own library. Now a class in our project has extended it. And this new class must somehow be introduced to Jetty as an authenticator. My opinion is that because SPNEGOAuthenticator class is using SecurityHandler, it has a function code similar to handlers (that is, a function similar to servlet and filter) that should be set in a file for what requests (with what url) will be sent to this class. Is this idea correct? if yes:
Question 1: How to introduce this new customized authenticator to Jetty during deployment process? Is it possible to introduce it in
Jetty context XML file
? I have not found an example of introducing authenticators in Google searching.Question 2: There are some variables in my customized class that need their values to be available when validateRequest method is called (such as initParams in Filters), where and how can the initial value of these variables be set? Can this be set in Jetty context XML file? If yes, please show me an example of its syntax.
Question 3: I need to tell jetty that the
loginService
feature inSecurityHandler
class should be initialized bySPNEGOLoginService
. How can I introduce this to jetty?