On Tue, Apr 11, 2017 at 12:42 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:
>
>> 1. There are no available hooks in Java EE to take advantage of to
>> introduce those
>>
>
> Not sure the point there since all containers would get these hooks. A JSR
> doesnt have to be portable but just to provide an API which can work so
> don't think it is a blocker.
>
It's not a blocker in the technical sense indeed. If we really wanted it,
such hook (its behaviour/SPI at least) could have been defined.
But unfortunately we just had very, very little resources. Basically 99% of
JSR 375 was developed from my side on the commute from and back home, as
that was all the time I had left.
It's an order of magnitude easier to use things that are already there,
then to invent / spec new ones ;)
> 2. There are very few if any existing mechanisms to use as examples for
> these containers
>
>> 3. Demand for them is quite low
>>
>
> Batch and @Async are not rare actually.
>
I agree, although I think what you want most here is a "login" method,
meaning; skip the authentication mechanism (since there's not always a
caller to interact with) and directly set the authenticated identity. Such
method was on the roadmap, but we just didn't get to it. Again, available
resources were incredibly low. I'm half surprised we still got as much done
as we did.
As a true authentication mechanism for @Asynchronous, yeah, that would be
cool. But some thinking would have to go into how it would exactly interact
with the caller. Throwing CDI events? The caller putting data in the event
as response?
From our previous discussions about @Asynchronous and the enhanced CDI
version of that, you probably remember how much I would have liked to see
that in Java EE 8, but because of time constraints it just didn't happen.
Also, regarding the @Asynchronous annotation, it would have needed some
cooperation of either the Concurrency spec or EJB spec, but neither were
active during EE 8 :(
> Well it is cause of AuthenticationStatus and HttpMessageContext
>
I wouldn't quite call that a state machine. AuthenticationStatus is mainly
so the code calling it programmatically knows what to do.
SUCCESS -> huray, we can use the principal. IN_PROGRESS -> The mechanism
took over the response and I can't touch the response myself now, FAILURE
-> I need to handle the failure somehow, i.e. by setting an error message.
Is that a state machine, or just handling a response code? I dunno ;)
> Maybe I missed something but the store doesn't secure by itself, I see it
> as the LoginModule for JAAS which is actually not the API you use to
> validate a context. So it is good it is not protocol specific (kudo on
> that) but we still miss some server in between no?
>
Indeed, the store doesn't secure by itself. It's a protocol independent
"database" of sorts. It's exactly like the LoginModule (LoginModule could
bridge to IdentityStore, another thing that was planned but not realised).
You put a credential in, you get an authenticated caller and optionally
groups out.
The one element that we didn't get to as mentioned above is something to
directly set the outcome into the container without a mechanism in between.
In terms of Servlet (but just as an example) that would correspond roughly
to what HttpServletRequest#login does behind the scenes.
Kind regards,
Arjan Tijms
>
>
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>>
>>> 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.
>>>>>
>>>>>
>>>>>
>>>
>>
>