Hi,
Although there's still *a lot* that needs to be taken care
of over at Eclipse regarding the transfer, we are able to
start the work for the next version of the API project and the
implementation in Soteria.
We already started with some small things such as fixing a
few warnings in Soteria, squashing a couple of bugs, and
re-installing the tests for Liberty. For the API a few
non-controversial things were added such as two extra wrappers
and annotation literals for the interceptor binding
annotations.
It probably would be good to think a little about what we'd
like to do with the API going forward.
Listening to some of the feedback I think the next version
should mainly be a continuation of the work done for 1.0. As
for the version number, I think 1.1 would be a good candidate
(I don't think anyone mentioned major breaking or
revolutionary changes warranting a 2.0 number).
A big difference this time is that both JASPIC and JACC are
open for changes as well. During JSR 375 we had the problem
that e.g. JASPIC wasn't open for changes since it wasn't
active, and it couldn't be made active since it wasn't planned
to be active.
This does mean we know have to make choices whether a
change should go into JASPIC, JACC, EE Security or in a
combination of these.
The things we can do vary between the boring but necessary
infrastructure/compatibility fixes, and some higher level user
features.
As for compatibility fixes:
We should have a clean way to fetch the caller principal
from a Subject. Discussed before and most supported was a
"Subject reader", which would be an interface implemented by
the container that knows how to return -the- caller principal
from a Subject. This is essentially the reverse of the JASPIC
CallerPrincipalCallback which writes the Principal.
At the end of JSR 375 we had some issues when Will used an
obscure clause in the JASPIC spec to escape from the
responsibility of having to provide the exact Principal in
e.g. HttpServletRequest#getUserPrincipal that was provided by
a SAM. The spec currently says it MUST be possible to
configure the container to return the exact Principal, but
doesn't say HOW this must be done. We should definitely fix
the wording here to prevent running into the same or similar
issues.
The group-to-role-mapper on which JACC depends was in scope
to be standardised, but we ran out of time.
As for user facing features:
The role checking interceptors weren't done for 1.0, but
are still very often asked for. We could decide to go for a
new annotation here which we can give more options for
example:
@RolesPermitted("foo")
public void someMethod();
@RolesPermitted(value = {"foo", "bar"}, semantics = AND)
public void someMethod();
@RolesPermitted(value = "foo", _onDenied_=EXCEPTION)
public void someMethod();
@RolesPermitted(value = "foo",
_onDenied_=START_HTTP_AUTHENTICATE)
public void someMethod();
We could also use the existing @RolesAllowed, with perhaps
an extra annotation tot set extra options.
@RolesAllowed( {"foo", "bar"} )
@RolesAllowedOptions(semantics = AND)
public void someMethod();
Multiple authentication mechanisms in various ways (next to
each other (per url pattern), stacked, and letting user
choose) has been mentioned before and was recently requested
again.
Custom authorisation rules is another one. I prototyped
this for 1.0, but there wasn't enough time to fully discuss
it. This would essentially provide a very user friendly API on
top of the low-level JACC providers. It would allow for things
such as checking roles with an external system (without having
to request all roles from that system in advance), setting
time based roles, adding and removing roles and constraints
for the application programmatically at startup in an easy
way, etc.
Adding a few additional authentication mechanisms such as
OAuth2 and JWT. There's a small complication here that MP has
defined a JWT authentication mechanism as well, so we may have
to find a way to align with that (in Payara the MP-JWT is
fully implemented as an EE Security authentication mechanism,
but other implementations didn't do that).
There's a bunch more we can do probably, but these are a
few of the things that immediately come to mind.
Kind regards,
Arjan
