Jetty Custom LoginService

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Jetty Custom LoginService

Gil Baruch
Hi,

I'm probably missing something otherwise this makes no sense...

I've been trying to use a custom login service for my webapp for a while already without success...

After lots of tries/readings I figured out the following:

1. Custom Login Service can be registered from either context deployer xml (preferred) or jetty-web.xml. I understood that the deployer is preferred because it is read first rather than the jetty-web which is read last... (though I don't understand the real impact in this context)

2. The custom Login Service class must be deployed as part of the server's classpath i.e. {jetty.base}/lib/etc. If deployed at {webapp}/WEB-INF/lib or {extra.classpath} (when extra.classpath is configured in the context deployer xml), it will not work and a ClassDefNotFound exception will be thrown.

3. It turns out that Jetty loads the class by using a server classloader rather than a webappcontext classloader of the webapp where it was configured. This means that the customLoginService has no access to the custom logic of the specific webapp which IMHO kind of kills the entire purpose of having a custom login service.

Lastly, I'm not willing to turn parentPriority setting to true mainly because that is the opposite of the standard and thus, I want to keep my project as close to the standard as possible.

What I'm currently thinking of is moving from the proprietary solution in Jetty to the standard JAAS based solution which I believe will let me have my custom logic in the authentication phase. However, it is more cumbersome IMO than the proposed LoginService alternative...

Your feedback is welcome.

thanks,
GBa.

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Jetty Custom LoginService

Jan Bartel
Gil,

You can very probably use an implementation of jetty's LoginService class that references classes from inside your webapp. To do that, you'd need to put your LoginService impl onto the server's classpath, and make it delegate to another class that is inside your webapp; define an interface for the delegate that you implement inside your webapp.  It won't work of course if you want to  reference your webapp's classes inside the constructor of your LoginService, but if you can confine references to webapp classes to the authentication method calls you should be ok.  You will also need to punch some holes in the serverClasses settings that are used to shield the webapp from access to jetty impl classes (see WebAppContext.prependServerClass() method).

You could also go the JAAS route, as I think (but haven't checked thoroughly) that the LoginContext will lazily delegate the loading of the LoginModule to the thread context classloader.  Of course, if you want to use any of the jetty impl classes to help with your implementation, you're back to punching holes in the serverClasses settings again.

The login/auth services have traditionally been services that are offered by the container to the webapp, with the webapp simply using the javax.servlet api in conjunction with the declarative security statements in web.xml to ensure portability across containers. The login/auth info generally exists in the container's environment, with appropriate role mappings to the webapp's environment to support portability.

cheers,
Jan

On 6 January 2018 at 17:46, Gil Baruch <[hidden email]> wrote:
Hi,

I'm probably missing something otherwise this makes no sense...

I've been trying to use a custom login service for my webapp for a while already without success...

After lots of tries/readings I figured out the following:

1. Custom Login Service can be registered from either context deployer xml (preferred) or jetty-web.xml. I understood that the deployer is preferred because it is read first rather than the jetty-web which is read last... (though I don't understand the real impact in this context)

2. The custom Login Service class must be deployed as part of the server's classpath i.e. {jetty.base}/lib/etc. If deployed at {webapp}/WEB-INF/lib or {extra.classpath} (when extra.classpath is configured in the context deployer xml), it will not work and a ClassDefNotFound exception will be thrown.

3. It turns out that Jetty loads the class by using a server classloader rather than a webappcontext classloader of the webapp where it was configured. This means that the customLoginService has no access to the custom logic of the specific webapp which IMHO kind of kills the entire purpose of having a custom login service.

Lastly, I'm not willing to turn parentPriority setting to true mainly because that is the opposite of the standard and thus, I want to keep my project as close to the standard as possible.

What I'm currently thinking of is moving from the proprietary solution in Jetty to the standard JAAS based solution which I believe will let me have my custom logic in the authentication phase. However, it is more cumbersome IMO than the proposed LoginService alternative...

Your feedback is welcome.

thanks,
GBa.

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--
Jan Bartel <[hidden email]>
www.webtide.com
Expert assistance from the creators of Jetty and CometD


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Jetty Custom LoginService

Gil Baruch
Hi Jan,

thank you for the detailed answer. However, I'm having some trouble figuring out your proposed solution.

Let's say that we have the following:

  1. CustomLoginService - placed in {jetty.base}/lib/etc
  2. WebappLoginService - Interface with few methods, placed also in {jetty.base}/lib/etc
  3. WebappLoginServiceImpl - implementation of the interface, placed in {jetty.base}/webapps/MyWebApp/WEB-INF/lib
if I follow you correctly, I should be adding WebappLoginServiceImpl FQN to the server classes by using the API (or system property). However, the definition of server class is:

Setting Server Classes

You can call the methods org.eclipse.jetty.webapp.WebAppContext.setServerClasses(String Array) ororg.eclipse.jetty.webapp.WebAppContext.addServerClass(String) to allow fine control over which classes are considered Server classes.

  • A web application cannot see a Server class.
  • A WEB-INF class can replace a Server class.

So, I'm assuming that you meant System class which is defined as:

Setting System Classes

You can call the methods org.eclipse.jetty.webapp.WebAppContext.setSystemClasses(String Array) or org.eclipse.jetty.webapp.WebAppContext.addSystemClass(String) to allow fine control over which classes are considered System classes.

  • A web application can see a System class.
  • A WEB-INF class cannot replace a System class.
However, even with system class, I'm failing to understand how it would become accessible from the server classloader... AFAIU, setting a class as system/server class is relevant for classes in the server not in the webapp...

bottom line I don't understand how I could access a webapp class from within the loginservice class...

thanks,
Gil.

On Mon, Jan 8, 2018 at 3:34 PM, Jan Bartel <[hidden email]> wrote:
Gil,

You can very probably use an implementation of jetty's LoginService class that references classes from inside your webapp. To do that, you'd need to put your LoginService impl onto the server's classpath, and make it delegate to another class that is inside your webapp; define an interface for the delegate that you implement inside your webapp.  It won't work of course if you want to  reference your webapp's classes inside the constructor of your LoginService, but if you can confine references to webapp classes to the authentication method calls you should be ok.  You will also need to punch some holes in the serverClasses settings that are used to shield the webapp from access to jetty impl classes (see WebAppContext.prependServerClass() method).

You could also go the JAAS route, as I think (but haven't checked thoroughly) that the LoginContext will lazily delegate the loading of the LoginModule to the thread context classloader.  Of course, if you want to use any of the jetty impl classes to help with your implementation, you're back to punching holes in the serverClasses settings again.

The login/auth services have traditionally been services that are offered by the container to the webapp, with the webapp simply using the javax.servlet api in conjunction with the declarative security statements in web.xml to ensure portability across containers. The login/auth info generally exists in the container's environment, with appropriate role mappings to the webapp's environment to support portability.

cheers,
Jan

On 6 January 2018 at 17:46, Gil Baruch <[hidden email]> wrote:
Hi,

I'm probably missing something otherwise this makes no sense...

I've been trying to use a custom login service for my webapp for a while already without success...

After lots of tries/readings I figured out the following:

1. Custom Login Service can be registered from either context deployer xml (preferred) or jetty-web.xml. I understood that the deployer is preferred because it is read first rather than the jetty-web which is read last... (though I don't understand the real impact in this context)

2. The custom Login Service class must be deployed as part of the server's classpath i.e. {jetty.base}/lib/etc. If deployed at {webapp}/WEB-INF/lib or {extra.classpath} (when extra.classpath is configured in the context deployer xml), it will not work and a ClassDefNotFound exception will be thrown.

3. It turns out that Jetty loads the class by using a server classloader rather than a webappcontext classloader of the webapp where it was configured. This means that the customLoginService has no access to the custom logic of the specific webapp which IMHO kind of kills the entire purpose of having a custom login service.

Lastly, I'm not willing to turn parentPriority setting to true mainly because that is the opposite of the standard and thus, I want to keep my project as close to the standard as possible.

What I'm currently thinking of is moving from the proprietary solution in Jetty to the standard JAAS based solution which I believe will let me have my custom logic in the authentication phase. However, it is more cumbersome IMO than the proposed LoginService alternative...

Your feedback is welcome.

thanks,
GBa.

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--
Jan Bartel <[hidden email]>
www.webtide.com
Expert assistance from the creators of Jetty and CometD


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Jetty Custom LoginService

Jan Bartel
Gil,

I'm attaching a small project to show what I mean. Look at the setup in the webapp subproject and run it with mvn jetty:run.

cheers
Jan

On 8 January 2018 at 21:27, Gil Baruch <[hidden email]> wrote:
Hi Jan,

thank you for the detailed answer. However, I'm having some trouble figuring out your proposed solution.

Let's say that we have the following:

  1. CustomLoginService - placed in {jetty.base}/lib/etc
  2. WebappLoginService - Interface with few methods, placed also in {jetty.base}/lib/etc
  3. WebappLoginServiceImpl - implementation of the interface, placed in {jetty.base}/webapps/MyWebApp/WEB-INF/lib
if I follow you correctly, I should be adding WebappLoginServiceImpl FQN to the server classes by using the API (or system property). However, the definition of server class is:

Setting Server Classes

You can call the methods org.eclipse.jetty.webapp.WebAppContext.setServerClasses(String Array) ororg.eclipse.jetty.webapp.WebAppContext.addServerClass(String) to allow fine control over which classes are considered Server classes.

  • A web application cannot see a Server class.
  • A WEB-INF class can replace a Server class.

So, I'm assuming that you meant System class which is defined as:

Setting System Classes

You can call the methods org.eclipse.jetty.webapp.WebAppContext.setSystemClasses(String Array) or org.eclipse.jetty.webapp.WebAppContext.addSystemClass(String) to allow fine control over which classes are considered System classes.

  • A web application can see a System class.
  • A WEB-INF class cannot replace a System class.
However, even with system class, I'm failing to understand how it would become accessible from the server classloader... AFAIU, setting a class as system/server class is relevant for classes in the server not in the webapp...

bottom line I don't understand how I could access a webapp class from within the loginservice class...

thanks,
Gil.

On Mon, Jan 8, 2018 at 3:34 PM, Jan Bartel <[hidden email]> wrote:
Gil,

You can very probably use an implementation of jetty's LoginService class that references classes from inside your webapp. To do that, you'd need to put your LoginService impl onto the server's classpath, and make it delegate to another class that is inside your webapp; define an interface for the delegate that you implement inside your webapp.  It won't work of course if you want to  reference your webapp's classes inside the constructor of your LoginService, but if you can confine references to webapp classes to the authentication method calls you should be ok.  You will also need to punch some holes in the serverClasses settings that are used to shield the webapp from access to jetty impl classes (see WebAppContext.prependServerClass() method).

You could also go the JAAS route, as I think (but haven't checked thoroughly) that the LoginContext will lazily delegate the loading of the LoginModule to the thread context classloader.  Of course, if you want to use any of the jetty impl classes to help with your implementation, you're back to punching holes in the serverClasses settings again.

The login/auth services have traditionally been services that are offered by the container to the webapp, with the webapp simply using the javax.servlet api in conjunction with the declarative security statements in web.xml to ensure portability across containers. The login/auth info generally exists in the container's environment, with appropriate role mappings to the webapp's environment to support portability.

cheers,
Jan

On 6 January 2018 at 17:46, Gil Baruch <[hidden email]> wrote:
Hi,

I'm probably missing something otherwise this makes no sense...

I've been trying to use a custom login service for my webapp for a while already without success...

After lots of tries/readings I figured out the following:

1. Custom Login Service can be registered from either context deployer xml (preferred) or jetty-web.xml. I understood that the deployer is preferred because it is read first rather than the jetty-web which is read last... (though I don't understand the real impact in this context)

2. The custom Login Service class must be deployed as part of the server's classpath i.e. {jetty.base}/lib/etc. If deployed at {webapp}/WEB-INF/lib or {extra.classpath} (when extra.classpath is configured in the context deployer xml), it will not work and a ClassDefNotFound exception will be thrown.

3. It turns out that Jetty loads the class by using a server classloader rather than a webappcontext classloader of the webapp where it was configured. This means that the customLoginService has no access to the custom logic of the specific webapp which IMHO kind of kills the entire purpose of having a custom login service.

Lastly, I'm not willing to turn parentPriority setting to true mainly because that is the opposite of the standard and thus, I want to keep my project as close to the standard as possible.

What I'm currently thinking of is moving from the proprietary solution in Jetty to the standard JAAS based solution which I believe will let me have my custom logic in the authentication phase. However, it is more cumbersome IMO than the proposed LoginService alternative...

Your feedback is welcome.

thanks,
GBa.

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--
Jan Bartel <[hidden email]>
www.webtide.com
Expert assistance from the creators of Jetty and CometD


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--
Jan Bartel <[hidden email]>
www.webtide.com
Expert assistance from the creators of Jetty and CometD


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

custom-loginservice.zip (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jetty Custom LoginService

Gil Baruch
Hi Jan,

I wanted to deeply thank you for the explanation along with the example which clarified everything.

So, thanks to you I was able to customize my login service. However, I was left with a few questions about this thing...

1. Does it make sense that one needs to play around that heavily with Jetty in order to simply have a custom login service?
2. Where does it ever say that jetty-web.xml loads classes by the webapp class loader while the context conf file loads classes by the server class loader


thanks a lot,
GBa.

On Tue, Jan 9, 2018 at 1:22 PM, Jan Bartel <[hidden email]> wrote:
Gil,

I'm attaching a small project to show what I mean. Look at the setup in the webapp subproject and run it with mvn jetty:run.

cheers
Jan

On 8 January 2018 at 21:27, Gil Baruch <[hidden email]> wrote:
Hi Jan,

thank you for the detailed answer. However, I'm having some trouble figuring out your proposed solution.

Let's say that we have the following:

  1. CustomLoginService - placed in {jetty.base}/lib/etc
  2. WebappLoginService - Interface with few methods, placed also in {jetty.base}/lib/etc
  3. WebappLoginServiceImpl - implementation of the interface, placed in {jetty.base}/webapps/MyWebApp/WEB-INF/lib
if I follow you correctly, I should be adding WebappLoginServiceImpl FQN to the server classes by using the API (or system property). However, the definition of server class is:

Setting Server Classes

You can call the methods org.eclipse.jetty.webapp.WebAppContext.setServerClasses(String Array) ororg.eclipse.jetty.webapp.WebAppContext.addServerClass(String) to allow fine control over which classes are considered Server classes.

  • A web application cannot see a Server class.
  • A WEB-INF class can replace a Server class.

So, I'm assuming that you meant System class which is defined as:

Setting System Classes

You can call the methods org.eclipse.jetty.webapp.WebAppContext.setSystemClasses(String Array) or org.eclipse.jetty.webapp.WebAppContext.addSystemClass(String) to allow fine control over which classes are considered System classes.

  • A web application can see a System class.
  • A WEB-INF class cannot replace a System class.
However, even with system class, I'm failing to understand how it would become accessible from the server classloader... AFAIU, setting a class as system/server class is relevant for classes in the server not in the webapp...

bottom line I don't understand how I could access a webapp class from within the loginservice class...

thanks,
Gil.

On Mon, Jan 8, 2018 at 3:34 PM, Jan Bartel <[hidden email]> wrote:
Gil,

You can very probably use an implementation of jetty's LoginService class that references classes from inside your webapp. To do that, you'd need to put your LoginService impl onto the server's classpath, and make it delegate to another class that is inside your webapp; define an interface for the delegate that you implement inside your webapp.  It won't work of course if you want to  reference your webapp's classes inside the constructor of your LoginService, but if you can confine references to webapp classes to the authentication method calls you should be ok.  You will also need to punch some holes in the serverClasses settings that are used to shield the webapp from access to jetty impl classes (see WebAppContext.prependServerClass() method).

You could also go the JAAS route, as I think (but haven't checked thoroughly) that the LoginContext will lazily delegate the loading of the LoginModule to the thread context classloader.  Of course, if you want to use any of the jetty impl classes to help with your implementation, you're back to punching holes in the serverClasses settings again.

The login/auth services have traditionally been services that are offered by the container to the webapp, with the webapp simply using the javax.servlet api in conjunction with the declarative security statements in web.xml to ensure portability across containers. The login/auth info generally exists in the container's environment, with appropriate role mappings to the webapp's environment to support portability.

cheers,
Jan

On 6 January 2018 at 17:46, Gil Baruch <[hidden email]> wrote:
Hi,

I'm probably missing something otherwise this makes no sense...

I've been trying to use a custom login service for my webapp for a while already without success...

After lots of tries/readings I figured out the following:

1. Custom Login Service can be registered from either context deployer xml (preferred) or jetty-web.xml. I understood that the deployer is preferred because it is read first rather than the jetty-web which is read last... (though I don't understand the real impact in this context)

2. The custom Login Service class must be deployed as part of the server's classpath i.e. {jetty.base}/lib/etc. If deployed at {webapp}/WEB-INF/lib or {extra.classpath} (when extra.classpath is configured in the context deployer xml), it will not work and a ClassDefNotFound exception will be thrown.

3. It turns out that Jetty loads the class by using a server classloader rather than a webappcontext classloader of the webapp where it was configured. This means that the customLoginService has no access to the custom logic of the specific webapp which IMHO kind of kills the entire purpose of having a custom login service.

Lastly, I'm not willing to turn parentPriority setting to true mainly because that is the opposite of the standard and thus, I want to keep my project as close to the standard as possible.

What I'm currently thinking of is moving from the proprietary solution in Jetty to the standard JAAS based solution which I believe will let me have my custom logic in the authentication phase. However, it is more cumbersome IMO than the proposed LoginService alternative...

Your feedback is welcome.

thanks,
GBa.

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--
Jan Bartel <[hidden email]>
www.webtide.com
Expert assistance from the creators of Jetty and CometD


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--
Jan Bartel <[hidden email]>
www.webtide.com
Expert assistance from the creators of Jetty and CometD


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Jetty Custom LoginService

Jan Bartel
Hi Gil,

Glad to hear you've had success.

1. Yes, it makes a lot of sense:  the authentication in the application container/servlet container world has always been a container responsibility. The touch point with the application is the nomination of the realm name in web.xml and any role mappings, or equivalent in annotations.  Section 13 Security of the Servlet Specification makes it clear that security is a container responsibility. Not even the programmatic interfaces allow the webapp to perform its own security - the best the app can do is to call back into the container to ask for authentication/authorization.  This must be the case because as @gregw pointed out in a conversation, once a user is authenticated by a webapp that user is then trusted by other webapps during a cross context dispatch call.

2. I think we do explain that in the documentation, but perhaps that is only obliquely, and maybe I'm thinking of all the times its come up in emails on the list :)  I've added an issue for us to make sure this is stated unambiguously in the doco:  https://github.com/eclipse/jetty.project/issues/2124

cheers
Jan

On 16 January 2018 at 00:44, Gil Baruch <[hidden email]> wrote:
Hi Jan,

I wanted to deeply thank you for the explanation along with the example which clarified everything.

So, thanks to you I was able to customize my login service. However, I was left with a few questions about this thing...

1. Does it make sense that one needs to play around that heavily with Jetty in order to simply have a custom login service?
2. Where does it ever say that jetty-web.xml loads classes by the webapp class loader while the context conf file loads classes by the server class loader


thanks a lot,
GBa.

On Tue, Jan 9, 2018 at 1:22 PM, Jan Bartel <[hidden email]> wrote:
Gil,

I'm attaching a small project to show what I mean. Look at the setup in the webapp subproject and run it with mvn jetty:run.

cheers
Jan

On 8 January 2018 at 21:27, Gil Baruch <[hidden email]> wrote:
Hi Jan,

thank you for the detailed answer. However, I'm having some trouble figuring out your proposed solution.

Let's say that we have the following:

  1. CustomLoginService - placed in {jetty.base}/lib/etc
  2. WebappLoginService - Interface with few methods, placed also in {jetty.base}/lib/etc
  3. WebappLoginServiceImpl - implementation of the interface, placed in {jetty.base}/webapps/MyWebApp/WEB-INF/lib
if I follow you correctly, I should be adding WebappLoginServiceImpl FQN to the server classes by using the API (or system property). However, the definition of server class is:

Setting Server Classes

You can call the methods org.eclipse.jetty.webapp.WebAppContext.setServerClasses(String Array) ororg.eclipse.jetty.webapp.WebAppContext.addServerClass(String) to allow fine control over which classes are considered Server classes.

  • A web application cannot see a Server class.
  • A WEB-INF class can replace a Server class.

So, I'm assuming that you meant System class which is defined as:

Setting System Classes

You can call the methods org.eclipse.jetty.webapp.WebAppContext.setSystemClasses(String Array) or org.eclipse.jetty.webapp.WebAppContext.addSystemClass(String) to allow fine control over which classes are considered System classes.

  • A web application can see a System class.
  • A WEB-INF class cannot replace a System class.
However, even with system class, I'm failing to understand how it would become accessible from the server classloader... AFAIU, setting a class as system/server class is relevant for classes in the server not in the webapp...

bottom line I don't understand how I could access a webapp class from within the loginservice class...

thanks,
Gil.

On Mon, Jan 8, 2018 at 3:34 PM, Jan Bartel <[hidden email]> wrote:
Gil,

You can very probably use an implementation of jetty's LoginService class that references classes from inside your webapp. To do that, you'd need to put your LoginService impl onto the server's classpath, and make it delegate to another class that is inside your webapp; define an interface for the delegate that you implement inside your webapp.  It won't work of course if you want to  reference your webapp's classes inside the constructor of your LoginService, but if you can confine references to webapp classes to the authentication method calls you should be ok.  You will also need to punch some holes in the serverClasses settings that are used to shield the webapp from access to jetty impl classes (see WebAppContext.prependServerClass() method).

You could also go the JAAS route, as I think (but haven't checked thoroughly) that the LoginContext will lazily delegate the loading of the LoginModule to the thread context classloader.  Of course, if you want to use any of the jetty impl classes to help with your implementation, you're back to punching holes in the serverClasses settings again.

The login/auth services have traditionally been services that are offered by the container to the webapp, with the webapp simply using the javax.servlet api in conjunction with the declarative security statements in web.xml to ensure portability across containers. The login/auth info generally exists in the container's environment, with appropriate role mappings to the webapp's environment to support portability.

cheers,
Jan

On 6 January 2018 at 17:46, Gil Baruch <[hidden email]> wrote:
Hi,

I'm probably missing something otherwise this makes no sense...

I've been trying to use a custom login service for my webapp for a while already without success...

After lots of tries/readings I figured out the following:

1. Custom Login Service can be registered from either context deployer xml (preferred) or jetty-web.xml. I understood that the deployer is preferred because it is read first rather than the jetty-web which is read last... (though I don't understand the real impact in this context)

2. The custom Login Service class must be deployed as part of the server's classpath i.e. {jetty.base}/lib/etc. If deployed at {webapp}/WEB-INF/lib or {extra.classpath} (when extra.classpath is configured in the context deployer xml), it will not work and a ClassDefNotFound exception will be thrown.

3. It turns out that Jetty loads the class by using a server classloader rather than a webappcontext classloader of the webapp where it was configured. This means that the customLoginService has no access to the custom logic of the specific webapp which IMHO kind of kills the entire purpose of having a custom login service.

Lastly, I'm not willing to turn parentPriority setting to true mainly because that is the opposite of the standard and thus, I want to keep my project as close to the standard as possible.

What I'm currently thinking of is moving from the proprietary solution in Jetty to the standard JAAS based solution which I believe will let me have my custom logic in the authentication phase. However, it is more cumbersome IMO than the proposed LoginService alternative...

Your feedback is welcome.

thanks,
GBa.

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--
Jan Bartel <[hidden email]>
www.webtide.com
Expert assistance from the creators of Jetty and CometD


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--
Jan Bartel <[hidden email]>
www.webtide.com
Expert assistance from the creators of Jetty and CometD


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--
Jan Bartel <[hidden email]>
www.webtide.com
Expert assistance from the creators of Jetty and CometD


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users