Do they plan a MR 1.2 or similar of JASPIC for Java EE 8 then?
Werner
On Tue, Mar 31, 2015 at 6:18 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Tue, Mar 31, 2015 at 5:56 PM, Darran Lofthouse
> <darran.lofthouse_at_redhat.com> wrote:
> > I think a lot is discussed in terms of HTTP but that is not the only
> entry
> > to an application server for the purpose of invocation.
>
> True, I mentioned this in the "CDI Authentication Events" thread. To
> quote myself here:
>
> "I didn't bring it up earlier since the discussions were already
> complex enough as they were, but one other thing we might need to take
> into account as well is logins/security inflow from other places than
> the web/servlet.
>
> Naturally everyone (including myself) is very focussed on web, but
> it's actually still possible to login via remote EJB and the JCA
> container."
>
>
> > Within HTTP we have authentication that can occur and be associated with
> a
> > session, there are then authentication mechanisms that continue to send
> > challenge responses with each subsequent request.
>
> Indeed, and this is where the natural stateless and "called with every
> request" nature of JASPIC authentication modules comes into play
> again. I demonstrated exactly this in the header based stateless token
> authentication article that I've mentioned a couple of times in these
> discussions (see
> http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
> ).
>
>
> > We also have SSO based
> > authentication where there could be a different lifecycle to the
> underlying
> > session.
>
> Absolutely, so authentication should definitely not be tied to a
> (HTTP) session by default.
>
> >Just looking at the epic dependencies I think this is going to be
> important as otherwise there is a risk that design of APIs around identity
> store could precede authentication mechanisms API design and the store
> design phase not have full access to the requirements.
>
> The question is whether we need to do much design for the
> authentication mechanism, since JASPIC in Java EE is already there and
> provides this. We would like a simplification of the bare (general)
> authentication module interface, which mostly boils down to supporting
> CDI and being typed for the Servlet container profile. The current
> authentication module interface is HTTP independent and can
> theoretically be used for anything. But this simplification issue has
> been raised in the JASPIC EG before and can be handled there.
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> > Then for non-HTTP we have a range from authentication on establishing a
> > connection to the server through to authentication associated with a
> > specific invocation.
> >
> > Regards,
> > Darran Lofthouse.
> >
>