| Re: [es-dev] EE Security.Next |
_______________________________________________Honestly it depends on the application. Over time I have seen @RolesAllowed work only about 60-70% of the time. I think an EL enabled authorization annotation will cover a further 80-90%. For the rest I am afraid it's down to using SecurityContext directly, perhaps in an interceptor most of the time. The annotation way is just a lot more easy and readable.
On 7/10/2018 12:15 PM, Erik Östlund wrote:
Is there a good case for offering authorization logic programming functionality via annotations? Most applications I've come across require a single group and the RolesAllowed annotation is a great fit for that.
I find the programmatic authorization style prevalent in many JAX-RS applications to be very readable plus it allows the developer to reuse that knowledge when working with other access control models:
@GET
@Path("{id}")
public Thing doGetById(@PathParam("id") Long id) {
Thing thing = thingRepository.find(id).orElseThrow(NotFoundException::new);
if (securityContext.isUserInRole("Employee") && securityContext.isUserInRole("Administrator")) {
throw new ForbiddenException();
}
return thing;
}
2018-07-09 1:44 GMT+02:00 arjan tijms <arjan.tijms@xxxxxxxxx>:
Hi,
On Sun, Jul 8, 2018 at 10:07 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
It does, but it has fixed OR semantics. You can’t change it to AND.
Why is it not possible to add more arguments like an enum with a default being OR but allowing others like AND?
I was slightly hesitant to propose that, since @RolesAllowed is from common annotations (JSR 250), that is used by many other things in the world. In Java EE that's EJB. I don't think anyone wants to update EJB at this point, but if we change @RolesAllowed it would be somewhat weird that all new attributes would only work in CDI and not in EJB. Various custom filters in JAX-RS as discussed above already interpret @RolesAllowed themselves, so changing this into a CDI intercepter binding annotation could result in some clashes and/or weird behaviour depending on whether the JAX-RS resource is also a CDI bean or not, and/or JAX-RS switches over to CDI completely.
A bit mentioned above, but to clarify; @RolesAllowed is currently a "plain" annotation, not a CDI interceptor binding one. There's ways around that. For example, a CDI extension could check for this annotation, and then add a CDI interceptor dynamically, but it's perhaps not as clean as starting with an annotation that's a CDI interceptor binding annotation from the start.
I'm not totally sure about what's best though, and maybe extending a already familiar annotation is easier for users, but just mentioning there are certain issues with doing that.
_______________________________________________Which API or Spec does @RolesPermitted("foo") belong to?
The Payara API has a CDI compatible RolesPermitted ;)
So I just took the name of that one. The final name of the annotation and its exact semantics have still to be decided of course.
Like Spring that is more or less a proprietary annotation so far.
If a separate new annotation was inevitable, that would of course increase maintenance efforts and blow up the overall Jakarta EE API because there are so many places using the common annotation.
Something like this challenge:is something we might want to look into. RolesAllowedDynamic may or may not be for ES, but the SecurityContext Jersey and JAX-RS have an exact duplicate should be derived from the ES one and at some later point deprecated or pruned
The MP-JWT spec has a requirement for a JAX-RS compatible @RolesAllowed as well. It clearly isn’t the right place to define this, but there simply was no other place for MicroProfile to put this, so it was more or less temporarily “dumped” in MP-JWT. (During a call the members already agreed to remove it as soon as it’s in JAX-RS or when a more appropriate spec can house it)
I implemented the roles allowed filter using standard jax-rs code. I only needed a Jersey specific api for registering it from the container side, since annotations aren’t being scanned there and JAx-rs doesn’t have a service loader extension mechanism like CDI.
The key difference with my implementation and jersey’s one is that jersey throws an exception when the caller is not authenticated at all, while mine starts the authentication process.
That's not the only redundancy and reinvention by MP. Config has a duality for some time, that REST-Client defined things that will ultimately have to move into JAX-RS over time, so having some duplication in MP-JWT is sad, but just one of many places that need cleanup.
I'm more concerned trying to reduce what is added to the spec/standard because that is much harder to remove after it was introduced, hence the question about possible options
Werner
I helped with a dynamic filter mechanism that uses Open API 2 (3 should offer even a bit more in that direction) allowing to declare the roles/groups in OpenAPI/Swagger.Maybe not directly part of the API (it used e.g. Swagger CodeGen to generate REST API templates which are properly annotated) but at the very least in a place like https://github.com/eclipse-ee4j/security-examples
Werner
On Sat, Jul 7, 2018 at 7:35 PM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,
On Sat, Jul 7, 2018 at 6:59 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
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.
With the proposed work there's various levels of checks, from simple to more elaborate:
There's the good old @RolesAllowed/Permitted which checks for a single role:
@RolesPermitted("foo")
public void someMethod()
There's the proposed EL based authorization annotation:
@IsAuthorized("hasRoles('Manager') && schedule.officeHours")
public void someMethod()
And there's the custom authorization rules:
@RolesPermitted("something")
public void someMethod()
OR
@WebServlet...
@ServletSecurity(@HttpConstraint(rolesAllowed = "something"))
And then:
@Overridepublic Boolean postAuthenticatePreAuthorizeByRole(Permission requestedPermission, Caller caller, SecurityConstraints securityConstraints) {return getRequiredRoles(securityConstraints.getPerRolePermissions(), requestedPermission).stream().anyMatch(role -> isInRole(caller.getCallerPrincipal().getName(), role));}}
(please don't look at the exact annotation and methods names too much, as they are just placeholders)
The EL based annotation is for more elaborate, but still relatively simple checks. The permission checks (role or url access), always go to the authorization module, which is currently in Java EE either a proprietary system (such as Elytron in WildFly), or standard JACC (such as in Payara and GlassFish).
In Java EE the JACC provider can be replaced fully, but it's an obscure and tedious job and few companies do this (a recent customer of Werner, whom I know as well, do use this, but they are the exception).
So in EE Security 1.1 the plan is to let the user add smaller and simpler modules that are called by the default JACC provider.
These modules can make programmatic decisions, and are essentially much like the EL that Reza proposed, but 1) are a Java method, and 2) can be added/replaced/removed independent of the code that is being protected. Such small rule modules can even be added from outside the application (i.e. added at the container level).
Kind regards,Arjan
_______________________________________________
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.RegardsRudy_______________________________________________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
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
_______________________________________________
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
_______________________________________________
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
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