Hi,
On Tue, Apr 11, 2017 at 12:20 AM, Werner Keil <werner.keil_at_gmail.com> wrote:
>
>
>> 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.
>
Indeed, the method in question that you mentioned is explicitly asking if
the user has access to a web resource. If the method is called in a context
where there is no web at all (a specifically configured server with no
Servlet Container present, something not possible in Java EE, but I think
Liberty can do that), the method would return false.
I may be a good idea to add that to the spec though.
Similarly, the authenticate() method/methods are web specific as well.
There's as of today as far as I know no meaningful way (not even
proprietary) to programmatically start an authentication dialog from a
non-web container. There was talk once about this (in the JASPIC EG years
ago) to look into this, but that never happened.
We addresses this a couple of times in the EG and at those times people,
including then spec lead Alex, mentioned they preferred emphasising the web
layer.
> 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?
>
JACC unites the Java SE security API with the Java EE security backbone. I
personally think that would not have been needed, they are two totally
separate security targets. Java EE security aims at securing known code
against an unknown user (the external caller), while Java SE aims at
securing unknown code (downloaded from the Internet) against a known caller
(yourself).
Nevertheless, JACC has the Java SE Policy and the Java SE Permission
classes at its central artefacts.
I personally think you could have pretty much exactly what JACC does today,
but simply cut the tie in with Java SE.
The JASPIC contains a LoginModule bridge profile, where it uses the
LoginModule from JAAS. But in all usages of every server JAAS is reduced to
a simple username/group provided.
For more info;
*
http://raymondkng.sys-con.com/node/171477
*
http://java.sys-con.com/node/1002315
*
https://blogs.oracle.com/nasradu8/entry/loginmodule_bridge_profile_jaspic_in
Kind regards,
Arjan Tijms
>
> 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
>>>>>
>>>>
>>>>
>>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Java EE Security API - JSR 375 - Experts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jsr375-experts+unsubscribe_at_googlegroups.com.
> To post to this group, send email to jsr375-experts_at_googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jsr375-experts/CAAGawe3TS4ONiky-_jtpMM3Z-
> xuPy2P2TJBi8%2BzyW%3DhmrzwToQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAAGawe3TS4ONiky-_jtpMM3Z-xuPy2P2TJBi8%2BzyW%3DhmrzwToQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>