On Tue, Oct 11, 2016 at 11:28 PM arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> Thanks for the forward of the minutes Alex, appreciate it!
>
> A few comments on the points raised:
>
>
> 1.
>
>
>
>
> 2. Alex raised
>
>
>
> 1. if we can eliminate EJB and JMS from Security
> Work.
>
>
> If I'm not mistaken, didn't we already largely agreed on that somewhere at
> the start of JSR 375?
>
> While standardising "something" for EJB and JMS was once planned (during
> Java EE 6), the fact that EJB is largely being de-emphasized now,
> especially for remote callers, combined with the fact that we wanted to go
> for the low hanging fruit, created little interest to include those.
>
> Specifically for the authentication mechanism we clearly indicated it was
> intended for HTTP only by calling
> it javax.security.authentication.mechanism.http.HttpAuthenticationMechanism.
>
> Somewhat of an exception is the SecurityContext. While this doesn't
> specifically do anything EJB specific the wish was that it should work
> "everywhere". I.e. if you do @Inject SecurityContext securityContext, it
> shouldn't matter if the injection target is in a Servlet, CDI bean, EJB, or
> whatever.
>
>
>
>
>
> 1. Simplifying Jaspic so it can work with all
> containers, would be a necessary first step. Reviewing
> the
> work Arjan has done in comparing the various containers
> would be a useful stepping stone. e.g. Can we require
> JASPIC
> be profiled for 375?
>
>
> JASPIC works with pretty much all containers today. Tomcat, Jetty, JBoss,
> GlassFish, Payara, Liberty, TomEE, WebLogic, Geronimo, JEUS, WebOTX,
> Hitachi AS and Fujitsu Interstage AS all support at least the Servlet
> Container Profile of JASPIC.
>
> Full JASPIC also specifies a profile for SOAP and a JAAS Bridge profile,
> but that's a bit de-emphasised as well. I've never really tested those.
>
> What exactly would there be to simplify for JASPIC here? Just requiring
> the Servlet Container Profile, or something else? There's btw also a JASPIC
> MR proposal pending, but that mainly seeks to put some clarifications in
> the spec. See
> https://java.net/projects/jaspic-spec/lists/users/archive/2015-11/message/0
>
> The Servlet spec in fact already recommends Servlet containers to support
> the Servlet Container Profile of JASPIC. It would help a lot though if
> "recommended" could be changed into "mandated" (see
> https://java.net/jira/browse/SERVLET_SPEC-114).
>
> As for the comparisons of containers, almost all servers are nearly
> perfect these days (this used to be quite different a few years ago). Only
> WebLogic introduced a major regression in 12.2.1 which I'm not sure has
> been fixed yet.
>
>
>
>
>
>
>
> 1. Will raised that a Java abstraction of OAuth
> Resources, Clients and Resource Owners is necessary.
>
> 2. There was a request to try and standardize a way to
> add users (I thought that was from Ivar).
>
>
>
> 1. I am not sure how viable that is given
> that identity systems typically manage the
> administration
> of users outside apps. But this can certainly be
> debated.
>
> Adding users was in Alex' original proposal for the identity store. We
> postponed that to a later moment, but the plan back then was to maybe have
> a sub-interface of the IdentityStore called ReadWriteIdentityStore or
> something like that.
>
> The rationale for postponing it was that none of the existing proprietary
> identity stores really have such a feature, and by going for the low
> hanging fruit we first wanted to standardise what was already out there.
>
> Secondly, while the feature is indeed quite nice, in practice an identity
> store is either an interface to something that already has its own
> management interface (like a corporate LDAP system), or the identity store
> is an interface that the container uses to access an application supplied
> identity store implementation. Such implementation often uses something
> like an application specific CDI/JPA based UserService. In that case the
> application doesn't need the identity store interface to add users, since
> it can already use its own UserService directly.
>
Most projects I am involved in manage their own users. That means that my
application's UserService will need to update/insert to the
userPrincipal/UserRole tables that e.g. WildFly is configured with. It will
also need to know the password encryption/hashing algorithm that are
configured for the domain to be able to support "change
password"/"forgotten password" functionality.
That kind of destroys portability for these applications (even if that
usually is no issue as we tend to stay with the same application server).
Ivar
>
>
>
>
>
>
> 1. There was also a request to start holding regular
> meetings -- weekly or bi-weekly, but regular.
>
>
> +1
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Java EE Security API - JSR 375 - Experts" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jsr375-experts+unsubscribe_at_googlegroups.com.
>
> To post to this group, send email to jsr375-experts_at_googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jsr375-experts/CAE%3D-AhD%3D3V%2BvOGDToE2TupVH5R6N_77fbJSexg_H73M4H9QGdw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAE%3D-AhD%3D3V%2BvOGDToE2TupVH5R6N_77fbJSexg_H73M4H9QGdw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
>