Hello Linda,
Bringing Arjan's question from the security JSR thread back to the umbrella
Java EE thread:
2017-04-11 17:33 GMT+02:00 arjan tijms <arjan.tijms_at_gmail.com>:
> Hi,
>
> From the JASPIC perspective, I don't think a MR would be needed for this.
> (I *really* would like to see a MR of JASPIC to clarify some other things
> though).
>
> JASPIC as said already defines profiles, so the Java EE Web Profile would
> basically only have to say it supports the "Servlet Container Profile of
> JASPIC 1.1/JSR 196".
>
> But perhaps Linda can give a more definite answer here.
>
> Kind regards,
> Arjan Tijms
>
>
>
> On Tue, Apr 11, 2017 at 4:57 PM, Werner Keil <werner.keil_at_gmail.com>
> wrote:
>
>> Arjan/all,
>>
>> Would this require a MR of JASPIC or other standards before the Java EE 8
>> release train?!
>>
>> If so, just like JPA (where it was announced but not yet filed) a MR
>> should be considered ASAP.
>>
>> Kind Regards,
>> Werner
>>
>>
>>
>>
>> On Tue, Apr 11, 2017 at 4:47 PM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>>> Hi Guillermo,
>>>
>>> Yes, I think what you ask could be accomplished, and unless someone
>>> completely disagrees I'll move forward doing just that.
>>>
>>> I know that some people think that indeed. I mean, I am probably the one
>>> who posted the most critiques against JASPIC ;) But I'm also firmly of the
>>> opinion that it's just a matter of fixing the problems in JASPIC (and JACC)
>>> one by one.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 11, 2017 at 3:41 PM, Guillermo González de Agüero <
>>> z06.guillermo_at_gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> My concern is that, as you know, some people who don't think JASPIC is
>>>> something to move forward.
>>>>
>>>> So my question is: would it be possible to remove the compilation
>>>> dependencies and maintain the wording of the spec, while theoritically
>>>> allowing someone to create a home-grown implementation, similar to JASPIC
>>>> but not being JASPIC at all?
>>>>
>>>> I don't know much about JAAS, but I read somewhere that the new WildFly
>>>> security library (Elytron) is no more backed by JAAS, although of course it
>>>> still supports JACC..
>>>>
>>>> I wonder if something like that could be done for JSR375.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Guillermo González de Agüero.
>>>>
>>>>
>>>> El mar., 11 de abril de 2017 11:13, arjan tijms <arjan.tijms_at_gmail.com>
>>>> escribió:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Tue, Apr 11, 2017 at 10:10 AM, Guillermo González de Agüero <
>>>>> z06.guillermo_at_gmail.com> wrote:
>>>>>
>>>>> My fault, you're right. JAX-RS is part of the WebProfile.
>>>>>
>>>>> Arjan, with the latest changes to the return enums you made, is JASPIC
>>>>> still strictly speaking a hard dependency?
>>>>>
>>>>>
>>>>> Yes, there's still a few types from JASPIC uses such as the
>>>>> AuthException and MessageInfoMap.
>>>>>
>>>>>
>>>>> If JASPIC is a concern, may the JSR 375 spec be reworded to mandate it
>>>>> *only* on the full profile and just recommend it on other environments?
>>>>>
>>>>>
>>>>> Difficult, since JASPIC exactly defines when the various methods are
>>>>> called, specifically the validateRequest method. Without JASPIC JSR 375
>>>>> would have to specify the behaviour of that exactly.
>>>>>
>>>>> Now we just say: see JASPIC
>>>>>
>>>>> Also note that the Web Profile does not need the full JASPIC spec,
>>>>> just the Servlet Container Profile (chapter 3 of the spec text). This is a
>>>>> bit like the Web Profile using EJB-lite instead of full EJB.
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Guillermo González de Agüero
>>>>>
>>>>> El mar., 11 de abril de 2017 10:02, Romain Manni-Bucau <
>>>>> rmannibucau_at_gmail.com> escribió:
>>>>>
>>>>> JAXRS is not part of webprofile? was in EE 7 so should be in EE 8 IMHO.
>>>>>
>>>>> Anyway back to security: the usage of jaspic is IMO a blocker, not
>>>>> integrated to CDI, not natural, and needs a lot of "tool" code to work
>>>>> (Arjan samples are great to realize it), so if EE security wants to use
>>>>> jaspic it should hide all that (and nicely make it not mandatory by that
>>>>> track, but that's just a nice side effect ;)). Said otherwise I kind of
>>>>> worry that to be usable we need omnifaces or a soteria tool module - not
>>>>> saying they are bad but that the entry cost is way too high.
>>>>>
>>>>> Concerning the "is SE in scope" I'm not sure but if you rephrase is
>>>>> "is not HTTP in scope" then it should be by design cause EE has concurrency
>>>>> utilities, jbatch, @Asynchronous, @Schedule etc... which can use security
>>>>> either by propagation or by direct late invocation. A very high part of
>>>>> these usages will not work with HTTP (note the propagation will be crucial
>>>>> and should be spec-ed at EE level to avoid a usage mess). If it is bridged
>>>>> and user still relies on HttpAuthenticationMechanism then the API is
>>>>> still unatural, will need mocking (which rarely helps to understand it) and
>>>>> will still require this state and protocol handling which will makes the
>>>>> adoption step way higher than it should be IMHO.
>>>>>
>>>>> For all these doubts I don't think we are ready to be prime time so
>>>>> full profile only is saner for this release until a huge amount of work is
>>>>> done.
>>>>>
>>>>> Side note 1: mvnrepository stats are limited which means they can't be
>>>>> use to check adoption (ex: deltaspike security api is more the ~ 2600
>>>>> download *last month*). This fully ignore ("normally") the company
>>>>> frameworks which are nuuuummmeeerous for security and all end user
>>>>> applications.
>>>>>
>>>>> Side note 2: not sure how polls help, think we should rather try on
>>>>> real application the API to see how it fits and what's the gap cause polls
>>>>> are really biaised, in particular on tweeter where network are partial
>>>>> until you hit 100k followers for most person retweeting.
>>>>>
>>>>>
>>>>>
>>>>> 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-11 9:36 GMT+02:00 Guillermo González de Agüero <
>>>>> z06.guillermo_at_gmail.com>:
>>>>>
>>>>> I personally think bringing JASPIC to the Web Profile is not a big
>>>>> deal since, as have been said, all mayor plain Servlet Containers already
>>>>> do that, and even the Servlet spec has been talking about explicitly
>>>>> requiring it.
>>>>>
>>>>> JACC is another story, but then, JSR 375 can work without it so that's
>>>>> not a problem at all.
>>>>>
>>>>> So big +1 from me on adding JSR 375 to the web profile, even if that
>>>>> needs to also pull JASPIC.
>>>>>
>>>>> El mar., 11 de abril de 2017 0:53, arjan tijms <arjan.tijms_at_gmail.com>
>>>>> escribió:
>>>>>
>>>>> Could be a good idea indeed.
>>>>>
>>>>> I'm of course strongly, strongly biased, but I know from application
>>>>> development and working with a lot of different devs in application
>>>>> development, that something like a basic security for JAX-RS endpoints in a
>>>>> fully portable and app controlled way is something that comes up each and
>>>>> every time.
>>>>>
>>>>>
>>>>> Interestingly, JAX-RS is not part of the Web Profile.
>>>>>
>>>>>
>>>>> Basically just something like defining this: (pre JSR 375 syntax)
>>>>>
>>>>> http://arjan-tijms.omnifaces.org/2014/11/header-based-statel
>>>>> ess-token.html
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 11, 2017 at 12:47 AM, reza_rahman <reza_rahman_at_lycos.com>
>>>>> wrote:
>>>>>
>>>>> If needed, I suggest doing a simple community poll (e.g. via Twitter)
>>>>> to help determine this. As I said, I suspect there is very strong desire
>>>>> for this functionality in all profiles.
>>>>>
>>>>> What do other people in this EG think? I know activity has been sparse
>>>>> for quite a few months, but surely we all have some opinions on this?
>>>>>
>>>>> -------- Original message --------
>>>>> From: reza_rahman <reza_rahman_at_lycos.com>
>>>>> Date: 4/10/17 4:38 PM (GMT-05:00)
>>>>> To: users_at_javaee-spec.java.net
>>>>> Subject: Re: [javaee-spec users] Re: [jsr366-experts] Java EE Security
>>>>> API
>>>>>
>>>>> I actually think what we have now is pretty useful. Given the strong
>>>>> support for security in all the Java EE surveys, I think it sends the wrong
>>>>> message not to include it in the Web Profile. I don't see that there is any
>>>>> future where the security API does not wind up in pretty much all
>>>>> significant Java EE profiles.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>