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.
>>>>
>>>>
>>>>
>>>>
>>
>