[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [es-dev] EE Security.Next
|
Hi,
On Sunday, July 8, 2018, Werner Keil <
werner.keil@xxxxxxxxx> wrote:
It does, but it has fixed OR semantics. You can’t change it to AND.
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.
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.
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.
Werner