[javaee-spec users] Re: [jsr366-experts] Java EE Security API

From: Romain Manni-Bucau <>
Date: Mon, 10 Apr 2017 23:02:17 +0200

2017-04-10 22:36 GMT+02:00 arjan tijms <>:

> Hi,
> On Mon, Apr 10, 2017 at 9:50 PM, Romain Manni-Bucau <
> > wrote:
>> can it stay outside WebProfile for EE 8? It seems security still requires
>> custom API or vendor specific API in enough cases
> It actually does need very little to no vendor specific APIs ;)

Was not "EE security API" but security in general. > 50% of cases I saw can
justify to not use a "common" (read as "standard" API) cause the
integration need is >> the gain due to company specific definition of

> Currently it mostly needs a vendor specific API to initialise CDI per
> request for some servers, since this is not well enough defined in any of
> the existing Java EE specs. But the overwhelming majority of the
> implementations out there already do the right thing. In practice, only
> Liberty initialises CDI a wee bit too late and would need to do something
> container specific (Soteria provides an SPI for that).
> Then for the security context there's an hasAccessToWebResource method.
> This actually would not need any vendor specific API, since Java EE's JACC
> provides functionality to implement this trivially.
> However, JACC is one of those other specs that people "fear" (unjustified
> if you ask me, but it is what it is for now). So on special request by spec
> lead Will there are no hard dependencies on JACC, just a reference to
> implement the algorithm such as defined by the Servlet and JACC specs.
> Naturally, every Servlet container internally already contains a way to
> determine "hasAccessToWebResource" and every Servlet container already
> parses web.xml for its security-constraints and applies an algorithm to
> match a concrete resource request (like /admin/foo) to a pattern (like
> /admin/*).
> JACC just formalises this really well.
I guess we can sadly say that JACC failed - no link to its quality in
itself - since it didnt get any traction for user code, of course, but also
libs (JTA is well integrated in a looot of libs). So my point was to ensure
current proposal is at the "right" level making it part of full EE profile
and if so "only" integrate it with web profile later (can likely end up
with a different flavor).

What I'm worrying about can be summarized mainly as 3 points:

1. the API is quite complex for no obvious gain (ex: it relies on a kind
state machine where most successful API don't - spring, deltaspike, shiro,
2. the API is quite bound to HTTP which makes the code quite hard to evolve
very quickly
3. @*Definition is quite crazy thinking about it if it doesn't provide some
override (in the spec, not soteria)...and also includes passwords in clear.

1 and 2 justifies my prudence, 3 is IMHO an abuse of @*Definition trend EE
tried to use. Since security is 100% CDI based it could rely on an event +
builder pattern (or anything fluent) which is more industriablizable and
allow to read passwords/credentials in a safe manner or hardcode them for
embed case (which is relatively rare for a ldap).

Kind regards,
> Arjan Tijms
>> (for good and bad reasons) and is easier not integrating with a 3rd party
>> (EE or not) in other numerous cases to not pollute the web profile with yet
>> another spec not yet helping much in enough cases.
>> +1 to get it in the full profile however, it is a very good move and next
>> version will hopefully make it more adapted to enterprises and
>> microservices and could imply a move to webprofile if accepted enough.
>> Probably wiser this way than the opposite which would enforce a stack for
>> EE > 8 not yet justified IMHO.
>> Romain Manni-Bucau
>> @rmannibucau <> | Blog
>> <> | Old Blog
>> <> | Github
>> <> | LinkedIn
>> <> | JavaEE Factory
>> <>
>> 2017-04-10 21:35 GMT+02:00 <>:
>>> Hi Linda and Security JSR EG,
>>> I think that majority of the people who care would warmly welcome this
>>> new security API also in Web Profile (many people already showed their
>>> preference on Twitter:
>>> However, I'd like to ask what are the implications? What other
>>> dependencies would it bring to the WebProfile?
>>> E.g. the Security JSR depends on JASPIC, which is not part of Web
>>> Profile. From the spec EDR1: " Integration with the servlet container
>>> leverages JASPIC;
>>> the container MUST configure and invoke the HttpAuthenticationMechanism
>>> via JASPIC, as
>>> described below"
>>> It seems to me that with the new Security JSR, also JASPIC needs to be
>>> moved to Web Profile. Is it really necessary or can the dependency on
>>> JASPIC be optional?
>>> I'd appreciate to make JASPIC optional and leave it out of Web Profile,
>>> because it's a cumbersome API and not really needed to be exposed in
>>> the Web Profile.
>>> Ondrej