Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [es-dev] EE Security.Next


Werner Keil | JCP Award Winner, JSR 385 Spec Lead | Eclipse UOMo Lead, EE4J Committer | Apache Committer | DWX '18 Track Chair, AdBoard Member

Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @TamayaConf | @OpenDDR | #EclipseUOMo

Skype werner.keil



On Sat, Jul 7, 2018 at 6:11 PM, Rudy De Busscher <rdebusscher@xxxxxxxxx> wrote:
I agree that we can start with the discussion of new features and implementation within Soteria.
It is also a good thing that changes can be introduced in JASPIC and/or JACC if needed. Although I have no idea how "active" these specs are or will be (since they have already some age and maybe not a lot of people are interested in taking care of it)

Other comments inline

On Sat, 7 Jul 2018 at 16:09, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
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).
We should take care not to introduce breaking changes. It will not be a good start. 

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.
+1 

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.
At least a default mapper when groups are equal to roles should be available by default. A simple SPI (interface) to do a mapping (which could map a single group to multiple roles) can solve already a lot of use cases. 


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();

I would go for the new annotation as it would give is more options. Use of EL _expression_, "custom voters" (= programmatic checks based on a class), ...

It would be good to allow programmatic checks as rebuilding static annotation code whenever a role or permission changes is not flexible enough in many large role and permission management situations.

About introducing a brand new annotation, what does that mean for  existing

Deprecating or pruning it would potentially break a lot of code that relies on it.

Spring also has a similar dilemma with two annotations including the standard one:

We would create something similar adding a new annotation.

Is it not possible to extend the existing one or did Oracle not contribute it to Jakarta EE?

If 
@RolesAllowed(value = {"foo", "bar"}, semantics = AND)
public void someMethod();

had a default value for "semantics" that makes sense (depending on how multiple roles are treated there now in combination) what prevents us from extending the one that's already there?


Werner
 
 

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.
I have this also implemented within Octopus and in this time of multiple authentication providers on internet it is a good idea. But I don't like the verbose way of defining it within web.xml. I used a properties file structure where the key is the URL pattern and the value is the authentication (and athorization) requirements. 


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.
+1 

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 is nothing wrong with multiple specifications or implementations using different underlying mechanisms. But we should take care that the JWT (and thus JWT structure - properties) which can be used for MicroProfile is also useable at Security EE. That way, it doesn't matter if we use MP or Jakarta EE based security, it will be accepted. if needed, we can propose improvements to the MP JWT Auth but structure should be kept aligned.

There's a bunch more we can do probably, but these are a few of the things that immediately come to mind.


Thanks for starting this up.
Regards
Rudy
 
Kind regards,
Arjan
_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/es-dev

_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/es-dev


Back to the top