In this case the most important thing seems to coordinate with this JSR;-)
Regards,
Werner
On Wed, Apr 1, 2015 at 2:01 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Wed, Apr 1, 2015 at 12:44 PM, Werner Keil <werner.keil_at_gmail.com>
> wrote:
> > Do they plan a MR 1.2 or similar of JASPIC for Java EE 8 then?
>
> Though nothing has been officially announced, I guess that will be the
> case then. I know from last time that the MR 1.1 was started without
> much prior announcements or long debates, but still got a few very
> important thing done.
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> > 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.
> >> >
> >
> >
>