On 17/12/14 14:09, Bill Burke wrote:
> On 12/16/2014 7:58 PM, Casey Lee wrote:
>> Yes, works fine on client side...ends up being rather abstract with
>> properties and I'd prefer to see auth more prominent. Either way, not
>> a big issue...I yield on the client side.
>>
>> As for server side, I'd still prefer to see something more declarative
>> on the resources. Specifically, I'd like to see something that deals
>> with the multiple parties involved with OAuth 2.0. Now maybe the
>> answer is "We don't want to have anything OAuth related in the API".
>> If that isn't the case, then it seems there ought to be two types of
>> annotations...one for permitting roles that the resource owner is in,
>> and the other for permitting roles from the scopes on the token.
>>
>
> OAuth 2 token formats are completely opaque and dependent on the vendor
> implementation. OAuth 2 doesn't define anything about
> permissions/roles. Neither does OpenID Connect. OIDC scopes are more
> about which claims the OIDC client wants in the IDToken.
>
> That being said, for our security solution [1] our tokens are built
> individually for each client and populated with the intersection of the
> user's role mappings and the client's allowed scope. So there's no need
> for a service to distinguish between user role mappings and client
> scope, the service just deals with @RolesAllowed.
>
I think having something like @Scopes and enforce a scope based AC is
interesting as it can offer a more involved AC compared to @RolesAllowed.
Given
https://tools.ietf.org/html/draft-richer-oauth-introspection-06#section-2.2
one can map a token to a list of scopes.
However it is probably unlikely it will make it into JAX-RS though...
That said I'll think of doing something like that in CXF, if I do then I
will publicly acknowledge it was Casey's idea
Sergey
> [1] http://keycloak.org
>