Hi,
Great that you got that feedback. I unfortunately missed Devoxx, but
watched Alex' talk online and there were quite some questions there.
On Mon, Nov 16, 2015 at 3:53 PM, Jean-Louis Monteiro <
jlmonteiro_at_tomitribe.com> wrote:
> - rather use user than caller for the consistency question
>
The most important thing is consistency of course, but the majority of the
experts were in favor of "caller". Might be a thing to get used too.
In Alex' question round I heard someone thinking that a "caller" was a
remote client, while a "user" was a local user in the application. Of
course this is not entirely the case as Alex replied, but it's
characteristic of the fact that people start to give different meanings to
things if the platform uses multiple terms.
> - CDI must be in the landscape - @Transactional used as a comparison of
> the thing to do. Antoine also opened the doors to collaborate.
>
There's no doubt about that, and till this far all the efforts have
strongly used CDI as a base, so we're right on track here.
> - Events - people overall really liked the event approach to either
> collect information about the authN/authZ process, or also to authenticate
> as we proposed in the playground.
>
The events as proposed till this far definitely. Events as a way to mimic a
single method call for the actual authentication, I'm not so sure if that's
the way. IMHO events work best as a notification system, or if multiple
(unknown) actors need to contribute to the end result.
> - Websocket - please do not forget it. What about HTTP/2 also.
>
Not really sure about those things yet. In Alex' talk people mentioned
JAX-RS (and tokens) and remote EJB though.
As for JAX-RS, that uses the exact same authentication mechanism as
Servlet, and we may even investigate if it makes sense to standardize an
authentication mechanism that's specifically well suited for JAX-RS. A
while ago I prototyped this one:
http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
There's no need to standardize the actual token format, just the
authentication mechanism that handles these. I think this is exactly what
Alex mentioned too.
Remote EJB is a tougher sell. There's no active EG at the moment, and
remote EJB itself is even half in danger of being pruned (for now only
CORBA though).
Yet, the identity store maps 1:1 to the proprietary concepts that current
servers now use, so JSR 375 could mean something for remote EJB as well.
For this we could either ask for a tiny EJB MR that just asks EJB
containers to check for the availability of a JSR 375 identity store, OR we
could put in our spec something like: "In a Java EE compliant product, the
EJB container has to take JSR 375 identity stores into account". With the
latter option no EJB MR is needed and vendors implementing full Java EE
would have to take that into account.
One overall feeling that I got is that many people already think 2 or 3
steps ahead, asking about advanced functionality. But as Alex explained
very nicely; we first need to tackle the very basics and pick the low
hanging fruit. After that, possibly for a Java EE Security 1.1 or 2.0 can
we start thinking about more fancy things.
Kind regards,
Arjan Tijms