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