> On Mar 8, 2019, at 5:39 AM, COURTAULT Francois > <francois.courta...@gemalto.com> wrote: > > Regarding the policy I would choose, most probably : Take the explicitly > mapped roles, add them on top of the "implicit" roles > But still I would have some concerns with this solution because you would > have 2 ways to define/declare roles either by the groups claim and by the > roles claims which could bring some confusion.
That would be my gut preference as well. Having the groups that were being enforced suddenly now "erased" through an add could get confusing to a novice. I definitely see the same concerns about there being more than one way to do it. There's a similar discussion/decision that was made in the Java EE Security specification on implicit roles -- treating groups as roles in relation to @RolesAllowed checks. In the back of my mind I have a feeling @RolesAllowed is overall legacy. In a JWT world, which I expect to last at least 10 years of dominance, really naming individual claims is what you want. There could be an @ClaimAllowed annotation that says the claim name and the allowed values. As tempting as that is to introduce, an idea I have cooking in the back of my mind is ... are we really looking at a bean validation use case? What if we treated the JWT as a bean and allowed people to apply bean validation rules to it? Bean Validation has pretty much solved the problem of how to apply (and reuse) business rules to a (potentially complicated) data structure and get a single thumbs-up or thumbs-down. I don't know how that would look yet, but there's definitely something to the idea. -David
