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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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) >>> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#setServerClasses%28java.lang.String%5B%5D%29> >>> ororg.eclipse.jetty.webapp.WebAppContext.addServerClass(String) >>> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#addServerClass(java.lang.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) >>> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#setSystemClasses%28java.lang.String%5B%5D%29> >>> or org.eclipse.jetty.webapp.WebAppContext.addSystemClass(String) >>> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#addSystemClass(java.lang.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 <[email protected]> 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 <[email protected]> >>>> 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 >>>>> [email protected] >>>>> To change your delivery options, retrieve your password, or >>>>> unsubscribe from this list, visit >>>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>>>> >>>> >>>> >>>> >>>> -- >>>> Jan Bartel <[email protected]> >>>> www.webtide.com >>>> *Expert assistance from the creators of Jetty and CometD* >>>> >>>> >>>> _______________________________________________ >>>> jetty-users mailing list >>>> [email protected] >>>> 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 >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>> >> >> >> >> -- >> Jan Bartel <[email protected]> >> www.webtide.com >> *Expert assistance from the creators of Jetty and CometD* >> >> >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> 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 > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel <[email protected]> www.webtide.com *Expert assistance from the creators of Jetty and CometD*
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
