Date: Tue, 16 Jul 2013 14:13:17 +0200
Hi,
On Monday, July 15, 2013, Werner Keil wrote:
> Markus/all,
>
> Thanks for the link. There are indeed a few JSRs that either didn't make
> it into EE 7 (like the 2 Cache-related ones) or were never intended for it
> from a schedule perspective (though some "widely respected IT magazine
> thought otherwise[?]) but should play a vital role under the hood and
> between other JSRs for EE 8.
>
> 350, 351 (it may not have the answer to all Security questions, but tries
> to address some, especially authentication, Single Sign-On, etc.)
>
>
Thanks for pointing out JSR 351 (Identity API) which I forgot to mention on
my blog. This has been in the works for some time, and it started to use
CDI relatively early on. So this one is surely a good example of security
infrastructure building on modern APIs.
Ron is probably the one most suited to answer this question, but I wonder
if the Identity API is going to be that overal "general" security framework
in Java EE that will replace/unify things like
HttpServetRequest#isUserInRole. I read through the available API a while
back but couldn't yet fully wrap my head around it. I'll make sure to take
another look soon though.
If it is however not intended to be that overal general security framework,
then having it around may actually complicate the situation for the end
user. There will then be JAAS, JACC, JASPIC, JIAPI (Java Identity API) and
portions of Servlet, EJB and JAX-RS all dealing with security. On top of
that if vendors (mainly) keep emphasizing their own technology for
authentication modules instead of JASPIC, then the end user has to deal
with that as well. Depending on the situation this will thus be a maximum
of 8 different technologies to deal with. In practice it's probably less,
but it's still a lot.
Kind regards,
Arjan Tijms
(image/gif attachment: 338.gif)