Hi,
On Tue, Apr 11, 2017 at 10:01 AM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:
> 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.
>
I understand your concerns (I really do), but you can be assured that's not
how JSR 375 is set up.
The HttpAuthenticationMechanism is not a central artefact on which the
entire security spec hinges, but the artefact that interacts with the
caller in an HTTP aka web environment. It delegates credential validation
to the IdentityStore.
If we would in a later stage want to support caller interaction in a JMS or
EJB/RMI environment, there could be a JmsAuthenticationMechanism and
RmiAuthenticationMechanism, which both would be their own top level types
and do not inherit from HttpAuthenticationMechanism.
An important thing to realise here is that the *AuthenticationMechanism
classes are the artefacts that interact with the caller, i.e. look at
requests, send responses, etc. They are by definition protocol (message
layer) specific.
We didn't went for JmsAuthenticationMechanism
and RmiAuthenticationMechanism because:
1. There are no available hooks in Java EE to take advantage of to
introduce those
2. There are very few if any existing mechanisms to use as examples for
these containers
3. Demand for them is quite low
4. The amount of resources JSR 375 was staffed with was quite low, so we
had to make choices
The HttpAuthenticationMechanism is also not a state machine, as I think you
mentioned. It's essentially a special type of javax.servlet.Filter, which a
few differences;
1. It's guaranteed to be called before and after all other Filters
2. The context used to set the authenticated identity is only valid within
the call to this special Filter
3. It can be called (indirectly) programmatically during the http request
The IdentityStore as mentioned above is unaware of any specific protocol
(message layer) and would be shared between authentication mechanisms used
for HTTP, JMS, RMI and what have you. So a hypothetical
JmsAuthenticationMechanism would delegate the credential validation to the
IdentityStore, just as the HttpAuthenticationMechanism does today.
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.
>>>
>>>
>>>
>