users@javaee-spec.java.net

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

From: Guillermo González de Agüero <z06.guillermo_at_gmail.com>
Date: Tue, 11 Apr 2017 14:55:37 +0000

Hi Arjan,

I think that makes the most sense.

But, IMO, The spec should anyway mandate to use JASPIC and JACC on the full
profile. This would just be a way to prevent cluttering reduced profiles,
and could help adoption on other projects (like Microprofile).


Regards,

Guillermo González de Agüero

El mar., 11 de abril de 2017 16:47, arjan tijms <arjan.tijms_at_gmail.com>
escribió:

> Hi Guillermo,
>
> Yes, I think what you ask could be accomplished, and unless someone
> completely disagrees I'll move forward doing just that.
>
> I know that some people think that indeed. I mean, I am probably the one
> who posted the most critiques against JASPIC ;) But I'm also firmly of the
> opinion that it's just a matter of fixing the problems in JASPIC (and JACC)
> one by one.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
> On Tue, Apr 11, 2017 at 3:41 PM, Guillermo González de Agüero <
> z06.guillermo_at_gmail.com> wrote:
>
> Hi,
>
> My concern is that, as you know, some people who don't think JASPIC is
> something to move forward.
>
> So my question is: would it be possible to remove the compilation
> dependencies and maintain the wording of the spec, while theoritically
> allowing someone to create a home-grown implementation, similar to JASPIC
> but not being JASPIC at all?
>
> I don't know much about JAAS, but I read somewhere that the new WildFly
> security library (Elytron) is no more backed by JAAS, although of course it
> still supports JACC..
>
> I wonder if something like that could be done for JSR375.
>
>
> Regards,
>
> Guillermo González de Agüero.
>
>
> El mar., 11 de abril de 2017 11:13, arjan tijms <arjan.tijms_at_gmail.com>
> escribió:
>
> Hi,
>
> On Tue, Apr 11, 2017 at 10:10 AM, Guillermo González de Agüero <
> z06.guillermo_at_gmail.com> wrote:
>
> My fault, you're right. JAX-RS is part of the WebProfile.
>
> Arjan, with the latest changes to the return enums you made, is JASPIC
> still strictly speaking a hard dependency?
>
>
> Yes, there's still a few types from JASPIC uses such as the AuthException
> and MessageInfoMap.
>
>
> If JASPIC is a concern, may the JSR 375 spec be reworded to mandate it
> *only* on the full profile and just recommend it on other environments?
>
>
> Difficult, since JASPIC exactly defines when the various methods are
> called, specifically the validateRequest method. Without JASPIC JSR 375
> would have to specify the behaviour of that exactly.
>
> Now we just say: see JASPIC
>
> Also note that the Web Profile does not need the full JASPIC spec, just
> the Servlet Container Profile (chapter 3 of the spec text). This is a bit
> like the Web Profile using EJB-lite instead of full EJB.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
> Regards,
>
> Guillermo González de Agüero
>
> El mar., 11 de abril de 2017 10:02, Romain Manni-Bucau <
> rmannibucau_at_gmail.com> escribió:
>
> JAXRS is not part of webprofile? was in EE 7 so should be in EE 8 IMHO.
>
> Anyway back to security: the usage of jaspic is IMO a blocker, not
> integrated to CDI, not natural, and needs a lot of "tool" code to work
> (Arjan samples are great to realize it), so if EE security wants to use
> jaspic it should hide all that (and nicely make it not mandatory by that
> track, but that's just a nice side effect ;)). Said otherwise I kind of
> worry that to be usable we need omnifaces or a soteria tool module - not
> saying they are bad but that the entry cost is way too high.
>
> Concerning the "is SE in scope" I'm not sure but if you rephrase is "is
> not HTTP in scope" then it should be by design cause EE has concurrency
> utilities, jbatch, @Asynchronous, @Schedule etc... which can use security
> either by propagation or by direct late invocation. 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.
>
> 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-stateless-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.
>
>
>
>
>