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.