users@javaee-spec.java.net

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

From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 11 Apr 2017 14:59:38 +0200

On Tue, Apr 11, 2017 at 2:24 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:

> Hi,
>
> On Tue, Apr 11, 2017 at 1:49 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com
> > wrote:
>
>> 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.
>>
>
> About the name "notify"; the idea was that it allows the user to return
> the credentials to the container, which then applies them after the user
> returns from the validateRequest method.
>
> They are not applied right away, hence the usage of notify.
>
> Another API design choice would have been been to return something akin to
> the current CredentialValidationResult, i.e. a type containing the return
> code, caller principal and groups.
>
> It gives the API a slightly different "feel", but ultimately does the
> exact same thing, of course.
>
> I put exactly this point up for discussion about a year ago, but there
> wasn't much response so I basically left it as is.
>
>
>
>> So if I try to summarize it seems a lot of shortcuts have been taken
>> cause of resources
>>
>
> Not so much shortcuts, but hard choices.
>
> In Alex' words; we went for the lowest hanging fruit first. This means the
> IdentityStore and the HttpAuthenticationMechanism are quite well thought
> out. We basically spend all our time on just those two, relatively small,
> things.
>
> So I agree, that the Java EE Security 1.0 spec is small. It has few
> features. We originally intended to have much, much more functionality,
> especially things like CDI based authentication events (login, logout
> events), a security method interceptor (kinda like @RolesAllowed, but more
> feature rich), and as my big interest, the custom authorization rules.
>
> There were even more proposals, like the multiple authentication mechanism
> story, an OAuth2 authentication mechanism, and JWT support.
>
> But we didn't do any of those, in favour of thinking out what we did add
> quite well.
>
> Many of those things WERE prototyped though. I extensively prototyped
> custom authorization rules and OAuth2. Rudy prototyped JWT, etc. But since
> those things were not deemed to be sufficiently ready and/or sufficiently
> discussed, we let them out.
>
>
>
>> 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.
>>
>
>
You scratch an itch with that.

While Spring at least on the outside makes the impression of continuity,
even there things are rapidly thrown away and replaced by other "cooler"
frameworks like Hystrix, Dropwizard,...

Antoine and I worked on OAuth support in Agorava, some of it could be a
great extension to JSR 375. There were discussions and rumors about JWT
support in MicroProfile. Right now, even the discussiond dried up several
months ago. And unless the corporate proprietary APIs around Auth0 (
https://auth0.com/) were to be the solution of choice, there seems almost
no widely spread solution out there on the JVM. JSON and JWT come from the
JavaScript world, so that's where you find most solutions nowadays. For
them Java is a 3rd or 5th citizen at best.

OK, I'm sure Spring Security got something, most likely wrapped around the
AIth0 platform and stack ;-)

Kind Regards,
Werner


> Those things can all be added in a 1.1 release. What's there now doesn't
> bite any of that, although I'm not quite sure what you mean with JAX-RS/CDI
> and CDI/Servlet scanning. CDI/servlet async, concurrency utilities/async
> and CDI/JAAS can absolutely be added later, although as mentioned some of
> those things would pretty much need an active EG for those other specs.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>