Hi,
On Fri, Dec 12, 2014 at 4:33 PM, Greg Wilkins <gregw_at_intalio.com> wrote:
>
> Arjan
>
> Your HttpHeaderAuthModule doesn't actually use anything else, not at least
> the version off the blog entry.
I guess you mean the one from
http://trajano.net/2014/06/creating-a-simple-jaspic-auth-module then.
That one wasn't made by me, but it's a good example in that it doesn't
depend on anything else indeed.
> 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
Okay, I'll take a look at that one.
Kind regards,
Arjan
>
> 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.