On Mon, Apr 10, 2017 at 11:02 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:
>
>
> 2017-04-10 22:36 GMT+02:00 arjan tijms <arjan.tijms_at_gmail.com>:
>
>> 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 ;)
>>
>
> 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
> security.
>
>
>>
>> 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,
> ...)
>
Spring (Security) is fairly popular:
https://mvnrepository.com/search?q=spring-security, nearly 550 other
publicly available libraries use Spring Security Core
Shiro seems reasonably popular with 300 usages of Shiro Core:
https://mvnrepository.com/search?q=shiro
DeltaSpike Security is barely worth mentioning with 12 usages:
https://mvnrepository.com/artifact/org.apache.deltaspike.modules/deltaspike-security-module-api
Seam (Security) has more downstream usages if you want to look at a popular
API despite it was officially stopped some while ago.
Another truly popular Security API would be PicketLink:
https://mvnrepository.com/search?q=picketlink
or
KeyCloak
https://mvnrepository.com/search?q=keycloak
Actually soon to be merged, but previous versions won't go away instantly
as Seam showed. Comparing them to say Spring is just a little harder if
projects keep being renamed or merged on a regular basis ;-)
Not everyone keeps being active and involved on a regular basis, but when
epics or stories were identified and terms defined earlier in the JSR's
lifecycle, then more dominant PicketLink and its contributors were also
involved or it taken into consideration.
> 2. the API is quite bound to HTTP which makes the code quite hard to
> evolve very quickly
>
I did raise some doubts about HTTP or "Web" usage in general, e.g. looking
at SecurityContext.
However, the somewhat comparable Spring Security elements and packages talk
about
"Classes related to the establishment of a security context for the
duration of a request (such as an HTTP or RMI invocation)."
So other than HTTP it aims at RMI, which is even a bit less used nowadays
(though still alive and kicking in several places)
Beside protocols or APIs that tend to be older and less used, JAAS support
by the Spring Principal wrapper could be an interesting though, but I know
JSR 375 is called "Java EE Security" so not sure, if Java SE Security APIs
would be in scope or not?
Regards,
Werner
> 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 <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
>>>>
>>>
>>>
>>
>