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.
Indeed, so I think basically everyone agrees that "1.1" should be next version number.
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.
Indeed, the mapper implementation that the container supplies can always do 1:1 and there's no obligation for any container to actually map groups to different things.
We *may* think of providing a standardised mapping format so that roles can optionally be mapped at an application level. This application level mapping would be independent of a container mapping that may or may not be there.
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), ...
Okay, as both you and Reza mention this, and it's also what I hear around most often, this is probably the way to go indeed.
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.
I think we can simply define this on the authentication mechanism (or *Definition), just like @WebServlet does:
@UrlPattern("/admin/*") // name needs more thinking
public class MyAuth implements HttpAuthenticationMechanism {
...
}
@UrlPattern("/rest/*") // name needs more thinking
public class MyRestAuth implements HttpAuthenticationMechanism {
...
}
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.
This definitely needs some thinking. Maybe it's an option to split out the actual JWT authentication mechanism to EE Security, then add EE Security (with a new JAX-RS profile) to MicroProfile.
I've been somewhat active in the MP-JWT project group, and my feeling is (but please correct me if I'm wrong), that the MP-JWT group was a little less interested in the actual JWT authentication mechanism, and far more interested in specifying the injection of the JWT token, the separate injection of the attributes of that token, and a great number of implicit conversions of the attribute values.
Here in EE Security I think we care less or not at all about those conversions, but are more interested in the authentication mechanism details.
Thanks for starting this up.
You're welcome!
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
