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