Hi,
On Sun, Sep 18, 2016 at 3:00 AM, Greg Wilkins <gregw_at_webtide.com> wrote:
> 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).
>
I think it's largely a chicken and egg problem.
If the vendors don't provide info about it, users don't know about. If
users don't know about it, they can't ask about it (can't ask about
something you don't know exists), so vendors may think there's no demand
and don't provide info about it.
> To make JASPIC relevant is going to need more than a bit of verbiage in
> the next servlet spec.
>
Do note that the recommendation to use JASPIC for custom authentication
modules is already there in the Servlet spec.
13.6.5 now says:
"To facilitate portable implementation and integration of additional
container authentication
mechanisms, it is recommended that all Servlet containers implement the
Servlet Container
Profile of The Java Authentication SPI for Containers"
My proposal was to change "recommended" into "mandated".
Whether that will immediately make a world of difference? Unlikely, but
it's a step by step process and this would be one of the many steps. Other
steps are addressing some spec omissions in JASPIC (I'm hoping to be able
to do/help with a JASPIC MR this year), making sure JASPIC works without
bugs everywhere (which is what I've been working at for the last 3~4 years)
and the JSR 375 effort (see below).
> We need some concrete actions that will actively encourage an eco system
> of authentication modules to evolve, like a few reference modules.
>
I agree with that. What types did you exactly had in mind, the JASPIC
equivalents of the existing Servlet authentication mechanisms, or something
else?
> 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.
>
Okay, thanks a lot for that ;)
> But I do stand by my point that unless it flourishes soon, it may be time
> to let it go.
>
With let it go, do you mean abandon the spec? Prune it?
If done so, do you also mean we should stop the JSR 375 effort (since
without JASPIC, it can't do what it does).
The point is that JASPIC itself is largely "just an SPI". It's a plug-in
point into the Servlet container's authentication machinery, and it's a
fairly low-level SPI. This is itself not the kind of thing that will become
extremely popular ever, simple because most people are not low level
library programmers. But as Steve Millidge from Payara demonstrated in his
Java Magazine article (
http://blog.payara.fish/custom-servlet-authentication-using-jaspic) even as
lower level SPI it's already quite usable.
JSR 375 however aims at providing those higher level abstractions that
application programmers are used to, but it needs a point to plug-in to the
Servlet container. If JASPIC had to dropped, JSR 375 would have to invent
it's own SPI and ask Servlet containers to implement that. This SPI would
be very close or almost exactly like JASPIC, except that it would not be
JASPIC. That would throw us back years, since we effectively have to redo
everything JASPIC already did.
Kind regards,
Arjan Tijms
>
> cheers
>
>
>
>
>
>
> 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_impleme
>> ntations-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
>