Hi,
On Mon, Apr 10, 2017 at 9:50 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
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 ;)
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.
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 <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-04-10 21:35 GMT+02:00 <ondrej.mihalyi_at_gmail.com>:
>
>> 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:
>> https://twitter.com/delabassee/status/851486773058433026)
>>
>> 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
>>
>
>