users@javaee-spec.java.net

[javaee-spec users] Re: [jsr366-experts] Java EE Security API

From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
Date: Tue, 11 Apr 2017 14:35:03 +0200

Issue is EE doesnt have a remove process well defined (for a good reason)
so if we add something then we'll not remove it even if we get a smooth API
in 2 years or for EE 9 which will quickly create a web profile = legacy
profile. This is less impacting for the full profile.


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 14:29 GMT+02:00 Werner Keil <werner.keil_at_gmail.com>:

> On Tue, Apr 11, 2017 at 2:13 PM, Ondrej Mihályi <ondrej.mihalyi_at_gmail.com>
> wrote:
>
>> Hi,
>>
>>
>>> So if I try to summarize it seems a lot of shortcuts have been taken
>>> cause of resources so regarding the addition or not of the spec to EE I
>>> think the question is: are we happy enough of current state to make it part
>>> of the platform or does it need more work to be at the level of something
>>> we want to support for year. For me it has a small of unfinished, in
>>> particular at platform level (at spec level itself it is usable with choice
>>> you agree or not). The lack of other spec integration is kind of a blocker.
>>> It hurts EE at several other places like CDI/servlet async, concurrency
>>> utilities/async, CDI/JAAS, JAX-RS/CDI, CDI/Servlet scanning, ... and each
>>> time it bites the platform and makes it look unfinished. Would be great to
>>> avoid it for the security which is very important for all companies and not
>>> a place where we can accept half full glass IMHO.
>>
>>
>> *In other words, are we OK with having at least something in the
>> WebProfile or we'd rather wait another couple of years until all is
>> polished?*
>>
>>
> With Java EE 8 and its current pace, it would not be more than another
> year, but I would rather have what is working out now.
> In an Agile and Iterative spirit of jcp.next (also see the adoption or
> Individuals often far more involved than companies, not to mention those
> who prefer to stay ouside th JCP;-|)
>
> Take MVC. While it is better to make it available to the community and
> allow Ivar plus a few others (similar to what Arjan et al did in 375) to
> get it Final there is still quite some doubt, if the industry would ever
> pick it up like e.g. the Batch JSR or (slower but in the Financial industry
> it moves at a different pace) and others were quickly adopted.
>
> Unless players like Vaadin or even Spring considered using it, hard to say
> how well it'll do. It is certainly far too late compared to Struts, Wicket
> or Spring MVC just to name 3 out of 300 or more MVC frameworks for the JVM
> alone.
>
>
>> The question is valid and full EE profile could provide an incubation for
>> the spec and after it's improved after real life feedback, it could become
>> part of Web Profile too. However, here are some objections from my side:
>>
>> - WebProfile is usually adopted faster, by more flexible companies and
>> runtimes, and before real adoption, we can't receive a relevant real-life
>> feedback. If the JSR is only in the full profile, the feedback would come
>> much later
>>
>> - From all the previous arguments, I don't see anything prevent a later
>> improvement while maintaining backward compatibility - the drawbacks
>> mentioned (mostly by Romain) are about what is missing, and not about what
>> is wrong and would possibly need to be changed in the future. The security
>> spec can be improved later in EE 9, specifying all the missing pieces. My
>> only concern is whether it can be easily integrated with other solutions to
>> provide the missing pieces, e.g. as a CDI extension or something else. I
>> guess the answer is "partially", but I think it's still far better than a
>> 100% custom solution for security. Projects like Omnifaces or Deltaspike
>> can provide the missing pieces until they are standardized later.
>>
>> - I understand that only a part of JASPIC, which applies to the servlet
>> container plus a few generic types, is required by the security JSR.
>> Therefore only a small portion of JASPIC is required and is already
>> available in Web Profile. This should be clarified in the Web Profile spec
>> if the security JSR becomes part of it.
>>
>>
> JASPIC is quite an old JSR https://jcp.org/en/jsr/detail?id=196 Hard to
> say, if "modularizing" it will be possible.
>
> Take CDI 2, it was a tedious and painful process to do this now and break
> it up into pieces, not so different from the never-ending "Jigsaw" effort
> in Java SE 9.
>
> Werner
>
>
>> Ondrej
>>
>> 2017-04-11 13:49 GMT+02:00 Romain Manni-Bucau <rmannibucau_at_gmail.com>:
>>
>>>
>>>
>>> 2017-04-11 13:37 GMT+02:00 arjan tijms <arjan.tijms_at_gmail.com>:
>>>
>>>>
>>>>
>>>> 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 ;)
>>>>
>>>
>>> Well you have the notify methods etc implying a state machine you need
>>> to know as a user. Put another name if you prefer but point was it is a big
>>> complicated as a central API.
>>>
>>>
>>>>
>>>>
>>>>
>>>>> 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.
>>>>
>>>
>>>
>>> So if I try to summarize it seems a lot of shortcuts have been taken
>>> cause of resources so regarding the addition or not of the spec to EE I
>>> think the question is: are we happy enough of current state to make it part
>>> of the platform or does it need more work to be at the level of something
>>> we want to support for year. For me it has a small of unfinished, in
>>> particular at platform level (at spec level itself it is usable with choice
>>> you agree or not). The lack of other spec integration is kind of a blocker.
>>> It hurts EE at several other places like CDI/servlet async, concurrency
>>> utilities/async, CDI/JAAS, JAX-RS/CDI, CDI/Servlet scanning, ... and each
>>> time it bites the platform and makes it look unfinished. Would be great to
>>> avoid it for the security which is very important for all companies and not
>>> a place where we can accept half full glass IMHO.
>>>
>>>
>>>>
>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>