[jsr369-experts] Re: [servlet-spec users] JASPIC; was: RFC7239 support

From: Greg Wilkins <gregw_at_webtide.com>
Date: Sun, 18 Sep 2016 11:00:45 +1000


Perhaps I was a little too off hand. My main complaint about JASPIC is
that it is just not used widely enough, nor is there significant demand
(and yes we missed that jetty post).

To make JASPIC relevant is going to need more than a bit of verbiage in the
next servlet spec. We need some concrete actions that will actively
encourage an eco system of authentication modules to evolve, like a few
reference modules.

I will follow the links in your post and update myself on the latest status
and see if there is more we can do to encourage it. But I do stand by my
point that unless it flourishes soon, it may be time to let it go.


On 17 September 2016 at 21:05, arjan tijms <arjan.tijms_at_gmail.com> wrote:

> 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_authenticati
> on-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

Greg Wilkins <gregw@webtide.com> CTO http://webtide.com