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.
>
> 1. There was also a request to start holding regular meetings --
> weekly or bi-weekly, but regular.
>
>
+1
Kind regards,
Arjan Tijms