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