Arjan
Your HttpHeaderAuthModule doesn't actually use anything else, not at least
the version off the blog entry. I have that working now, but I had to
update our impl to handle a return of FAILURE.
This conversation is now probably off topic for this list, so I have opened
a Jetty issue to discuss further as I decode the feedback you have given.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=455047
For the purposes of this list, I repeat that I do like the concept of
JASPIC and am not opposed to replacing the baked in authentication
mechanisms with something extensible.
cheers
On 12 December 2014 at 15:34, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> Hi,
>
> On Fri, Dec 12, 2014 at 2:30 PM, Greg Wilkins <gregw_at_intalio.com> wrote:
> >
> > Arjan,
> >
> > I've started having a bit of a look at this in jetty. It's like an
> > archaeological dig discovering code not used for some time!
> >
> > Note that jetty does have BASIC/DIGEST/FORM etc. implemented
> >
> >
> https://github.com/eclipse/jetty.project/tree/master/jetty-jaspi/src/main/java/org/eclipse/jetty/security/jaspi/modules
>
> Wow, looks like a great start.
>
> >
> > But this code has been untested/unused for a while. I'll wake it up
> with
> > a few test harnesses and then try out some of your modules. If you
> wanted
> > to cast your expert eye over them to see if they look approximately
> correct,
> > that would be handy.
>
> I did a quick look, and saw a few things:
>
> // not mandatory or its the login or login error page don't authenticate
> if (!mandatory ||
>
> isLoginOrErrorPage(URIUtil.addPaths(request.getServletPath(),request.getPathInfo())))
> return AuthStatus.SUCCESS;
>
> While a lot of (early) auth modules just returned SUCCESS when "doing
> nothing", the idea is to actually only return SUCCESS when the
> CallerPrincipalCallback has been handled. If nothing needs to be done,
> the CallerPrincipalCallback can be invoked with a null as follows:
>
> handler.handle(new Callback[] { new
> CallerPrincipalCallback(clientSubject, null) });
>
> I've put this on the Javadoc of the "doNothing" method from the
> example I referenced as:
>
> /**
> * Instructs the container to "do nothing".
> *
> * <p>
> * This is a somewhat peculiar requirement of JASPIC, which
> incidentally almost no containers actually require
> * or enforce.
> *
> * <p>
> * When intending to do nothing, most JASPIC auth modules simply
> return "SUCCESS", but according to
> * the JASPIC spec the handler MUST have been used when returning
> that status. Because of this JASPIC
> * implicitly defines a "protocol" that must be followed in this case;
> * invoking the CallerPrincipalCallback handler with a null as the
> username.
> *
> * <p>
> * As a convenience this method returns SUCCESS, so this method
> can be used in
> * one fluent return statement from an auth module.
> *
> * @return {_at_link AuthStatus#SUCCESS}
> */
>
> Another thing that I noticed:
>
> boolean success = tryLogin(messageInfo, clientSubject, response,
> session, username, new Password(password));
> if (success)
> {
>
> [...]
>
> response.sendRedirect(response.encodeRedirectURL(nuri));
> return AuthStatus.SEND_CONTINUE;
> }
>
> Where tryLogin among others does this when returning true:
>
> CallerPrincipalCallback callerPrincipalCallback = new
> CallerPrincipalCallback(clientSubject,
> loginCallback.getUserPrincipal());
> GroupPrincipalCallback groupPrincipalCallback = new
> GroupPrincipalCallback(clientSubject, loginCallback.getRoles());
>
> callbackHandler.handle(new Callback[] { callerPrincipalCallback,
> groupPrincipalCallback });
>
> If SEND_CONTINUE is returned, then the invocation of the handler that
> was done in tryLogin is to be ignored.
>
> Because JASPIC is effectively stateless, it would not really make
> sense to authenticate and directly redirect. In Java EE 7 an extra
> option was added so the authentication is semi-remembered, so it might
> make sense in that case.
>
> At any length, because of the stateless aspect the module should check
> if there's an existing login remembered somewhere (e.g. put in the
> session) and then re-authenticate at the start of validateRequest.
>
> I'll take a more in-depth look later if needed ;)
>
> > Would you mind if I added your HttpHeaderAuthModule as a test/example ?
>
> Not at all, but do note it depends on a library called OmniSecurity
> that I've been incubating.
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> > cheers
> >
> >
> >
> >
> >
> >
> > On 9 December 2014 at 18:43, Greg Wilkins <gregw_at_intalio.com> wrote:
> >>
> >>
> >> Arjan,
> >>
> >> it sounds like things have moved on since we last looked at this in any
> >> detail. The fact that there are some OAuth and other modules
> available
> >> is definitely a huge improvement.
> >>
> >> At one stage, Jetty also considered just having JASPI support and
> >> implementing the FORM/BASIC/DIGEST methods as modules.
> >>
> >> I'll try to find the time to experiment with your modules in Jetty (and
> >> probably will have to update our JASPI impl), to gain experience with
> the
> >> current state of the art.
> >>
> >> As I said, I like the concept of the approach and in theory having
> servlet
> >> 4 only support JASPIC with 4 mandatory modules is attractive.
> >>
> >> I'll report back once I've got some modules working.
> >>
> >> cheers
> >>
> >>
> >>
> >> On 9 December 2014 at 16:49, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Tue, Dec 9, 2014 at 1:57 PM, Greg Wilkins <gregw_at_intalio.com>
> wrote:
> >>> > On 9 December 2014 at 13:31, Mark Thomas <markt_at_apache.org> wrote:
> >>> > But the main failing of the approach, is that to my knowledge, nobody
> >>> > uses
> >>> > it!
> >>>
> >>> Part of this is, IMHO, because of the chicken/egg problem, or Mexican
> >>> standoff if you like.
> >>>
> >>> Just two years ago, JASPIC wasn't just unknown, it also wasn't really
> >>> functional in most containers. There was barely something that worked
> >>> everywhere. Lack of TCK coverage was maybe a factor here. So as I
> >>> understood, the users who did try JASPIC (e.g. after being curious of
> >>> what this new thing added in Java EE 6 was about) were put off by the
> >>> fact that nothing really worked.
> >>>
> >>> So for those last two years I contacted multiple vendors and worked
> >>> with them to improve their implementations. Nearly all of those
> >>> vendors really were extremely helpful and have improved their
> >>> implementations immensely. In parallel with that effort I've created a
> >>> series of unit tests for JASPIC (see
> >>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic)
> >>> and validated a lot of my assumptions there with Ron Monzillo, who has
> >>> been incredibly helpful in clarifying a lot of behavior.
> >>>
> >>> Next to that, a small but critical number of issues in the spec was
> >>> identified during the Java EE 6 lifetime and subsequently addressed in
> >>> Java EE 7's MR of JASPIC in cooperation with the Servlet spec (e.g.
> >>> via the addition of getVirtualServerName() to the ServletContext).
> >>>
> >>> With JASPIC now being in a much better state, I feel it's ready for
> >>> the next step.
> >>>
> >>> > At least not with Jetty. Perhaps there may have been a few users
> when
> >>> > Jetty was part of the Geronimo container (as IBM via Geronimo were
> the
> >>> > main
> >>> > driver for our implementation), but since those days, I have not
> seen a
> >>> > single question or usage of JASPI nor any 3rd party authentication
> >>> > modules.
> >>>
> >>> Well, following my articles about JASPIC I've been contacted by about
> >>> a dozen of people regarding JASPIC. A dozen may not sound like much,
> >>> but it's surely more than nobody at all. Just recently on the EE
> >>> mailing list:
> >>>
> >>> "here at BMW we use a framework built on top of JACC /
> >>> JASPIC to connect our Java EE 6 Application Servers (GlassFish,
> >>> WebLogic) to our Web EAM Infrastructure for a Java EE 6 compliant,
> >>> application server independent authentication and authorisation"
> >>>
> >>> See:
> >>>
> https://java.net/projects/javaee-spec/lists/users/archive/2014-12/message/6
> >>>
> >>> And there are surely a bunch of 3rd party authentication modules out
> >>> there (including my own), especially now people are slowly discovering
> >>> that the latest implementations of JASPIC in current containers do
> >>> work.
> >>>
> >>> A few examples:
> >>>
> >>> 1. OAuth 2.0 JASPIC auth module -
> >>> http://trajano.net/2014/07/oauth-2-0-jaspic-implementation
> >>> 2. Header based JASPIC auth module -
> >>> http://trajano.net/2014/06/creating-a-simple-jaspic-auth-module
> >>> 3. CAS JASPIC auth module - https://code.google.com/p/cas-jaspic
> >>> 4. OpenId JASPIC auth module -
> >>>
> >>>
> http://www-02.imixs.com/roller/ralphsjavablog/entry/openid_serverauthmodule_jsr_196_with
> >>> 5. Header/staless JASPIC auth module -
> >>>
> >>>
> http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
> >>> 6. SocialAuth (Oath1, Oath2, etc) auth module -
> >>>
> >>>
> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/SocialServerAuthModule.java
> >>> 7. JSF optimized FORM auth module -
> >>>
> >>>
> https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/OmniServerAuthModule.java
> >>>
> >>> > The only way that I could see JASPI as part of the servlet spec, is
> if
> >>> > we
> >>> > all agreed to deprecate all container authentication in 4.0 and
> support
> >>> > JASPI as the primary authentication mechanism. Only with something
> like
> >>> > that would it be likely that truly portable and innovative
> >>> > authentication
> >>> > mechanisms would evolve and thus drive demand.
> >>>
> >>> That surely would be a great next step indeed. Having the 4 standard
> >>> authentication "mechanisms", meaning BASIC, FORM, DIGEST, and
> >>> CLIENT-CERT implemented as JASPIC auth modules would make the entire
> >>> authentication system a lot clearer. There would basically be JASPIC
> >>> as the primary SPI/API, and then Servlet containers would ship with 4
> >>> standard modules that all used that API.
> >>>
> >>> JBoss at one time has indeed been doing this;
> >>>
> >>> 1. BASIC JASPIC auth module -
> >>>
> >>>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.as/jboss-as-web/7.2.0.Final/org/jboss/as/web/security/jaspi/modules/HTTPBasicServerAuthModule.java
> >>> 2. FORM JASPIC auth module -
> >>>
> >>>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.as/jboss-as-web/7.2.0.Final/org/jboss/as/web/security/jaspi/modules/HTTPFormServerAuthModule.java
> >>> 3. CLIENT-CERT JASPIC auth module -
> >>>
> >>>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.as/jboss-as-web/7.2.0.Final/org/jboss/as/web/security/jaspi/modules/HTTPClientCertServerAuthModule.java
> >>>
> >>> > If there were JASPI implementations for OAUTH, Kerboros etc
> available,
> >>> > then
> >>> > that may also drive adoption, but as far as I can tell, those that
> use
> >>> > JASPI
> >>> > do so for their own proprietary mechanisms.
> >>>
> >>> That too, but see the list above. There are at least two OAuth JASPIC
> >>> module implementations.
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> >
> >>> > cheers
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Greg Wilkins <gregw_at_intalio.com> @ Webtide - an Intalio subsidiary
> >>> > http://eclipse.org/jetty HTTP, SPDY, Websocket server and client
> that
> >>> > scales
> >>> > http://www.webtide.com advice and support for jetty and cometd.
> >>
> >>
> >>
> >>
> >> --
> >> Greg Wilkins <gregw_at_intalio.com> @ Webtide - an Intalio subsidiary
> >> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> >> scales
> >> http://www.webtide.com advice and support for jetty and cometd.
> >
> >
> >
> > --
> > Greg Wilkins <gregw_at_intalio.com> @ Webtide - an Intalio subsidiary
> > http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> > http://www.webtide.com advice and support for jetty and cometd.
>
--
Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.