2017-04-11 12:35 GMT+02:00 arjan tijms <arjan.tijms_at_gmail.com>:
> 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
>
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.
> 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.
> 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
>
>
Well it is cause of AuthenticationStatus and HttpMessageContext
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.
>
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?
>
> 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.
>>>>
>>>>
>>>>
>>
>