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.
>> >
>
>