Hi,
On Sat, Sep 17, 2016 at 2:13 AM, Greg Wilkins <gregw_at_webtide.com> wrote:
> While Jetty has (does?) support JASPIC, the uptake of it as a feature has
> been zero as far as we know.
>
Do you mean in Jetty, or in general? There was a question about Jetty and
JASPIC on the jetty-users list a month or so ago:
https://dev.eclipse.org/
mhonarc/lists/jetty-users/msg07258.html
In general it has certainly not been zero, although it had a slow start due
to several factors (very little promotion, very small and incomplete TCK,
very limited availability).
There's a number of (OSS) auth modules readily available now, which
includes Kerberos/SSO, AzureAD, OAuth2, CAS, OpenID, SPNEGO, etc. See
https://jaspic.zeef.com/arjan.tijms#block_63041_authentication-modules-sams-
Here I'm trying to address the availability. The fact that say a Filter is
everywhere available but an AuthModule historically only on a full Java EE
implementation did certainly not help. Specs like BeanValidation or JMS can
be rather easily added to other environments, but JASPIC is mostly
something a Servlet container has to do, it's not a separate jar that you
add to your app.
> It is likely that our support for it has atrophied and it would be a
> massive surprise if a 3rd party auth module was to emerge and work out of
> the box with jetty.
>
Possibly, but I remember from our discussion from last year you seemed
rather enthusiastic about it back then and were going to look into the
existing JASPIC implementations of FORM, BASIC, etc that Jetty already has.
What changed, or did I misinterpret you as being somewhat enthusiastic back
then?
> As a spec, somebody should either kill JASPIC or make it a used spec. I'm
> not sure if a few words in this spec saying it is an optional feature will
> help takeup, but I guess it would not hurt. Perhaps a reference auth
> module would be useful that we could all integrate and thus discover
> anything extra that might need to go in our spec to make interoperability
> actually work?
>
Such reference auth module would absolutely be useful.
Close to that, I created a series of IT tests over the course of ~3 years
that test many aspects of JASPIC using test auth modules. See
https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
I periodically test a number of servers, see e.g. the latest report from
June:
http://arjan-tijms.omnifaces.org/2016/06/the-state-of-portable-authentication-in.html
I've had some questions about including Jetty and doing a Servlet only test
run, so this is something I'd really like to look at soon.
Furthermore, the Java EE Security API (JSR 375) builds higher level/user
friendlier functionality on top of JASPIC. See the RI (Soteria) here:
https://github.com/javaee-security-spec/soteria
This JSR indeed contains a number of reference auth modules (authentication
mechanisms) and tests for it. These tests are run on multiple servers and
thus indirectly exercise the JASPIC implementation of each server. Until so
far this has indeed led to the discovery of a number of bugs (see
https://jaspic.zeef.com/arjan.tijms#block_63051_implementations-issue-tracking),
but surprisingly few omissions in the JASPIC spec were found. The ones that
were found are mostly listed here:
https://java.net/projects/jaspic-spec/lists/users/archive/2015-11/message/0
Hope this makes things more clear.
Kind regards,
Arjan Tijms
>
> regards
>
> --
> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>