MP JWT propagation specification clarification

[COURTAULT Francois <Fr...@gemalto.com>]

Hello,

Reading the JWT propagation 1.0 specification, it is mentioned :

·         Chapiter 4:  "groups": The token subject's group memberships that will be mapped to Java EE style

application level roles in the MicroProfile service container."

·         Chapiter 4 §4.1 Minimum MP-JWT Required Claims (page 9): "This typically will required a mapping at the application container level to
application deployment roles, but a one-to-one between group names and application role names is required to be performed in addition
to any other mapping."

My  understanding is:

·         If the JWT only have the required custom claim groups and let's say  we have in this one "group1", "group2", "group3", it means that, if no mapping is provided,
the entity represented by the jwt has the roles "group1", "group2", "group3". Is it right ?

·         In the spec, §4.2 Additional Claims, we may have a new custom claim "roles" (example provided at page 12 "auditor", "administrator").
It means that the entity represented by the jwt has the roles "auditor" and "administrator" and  belongs to the groups "red-group","green-group","admin-group".
Is it right ?

BTW, how and where to declare the groups and roles mapping in TomEE ?  in openejb-jar.xml ? other location ?

Best Regards.
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

Re: MP JWT propagation specification clarification

[David Blevins <da...@gmail.com>]

> On Mar 8, 2019, at 5:39 AM, COURTAULT Francois <Fr...@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

RE: MP JWT propagation specification clarification

[COURTAULT Francois <Fr...@gemalto.com>]

Hello David,

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.

Best Regards.

-----Original Message-----
From: David Blevins [mailto:david.blevins@gmail.com]
Sent: jeudi 28 février 2019 00:10
To: users@tomee.apache.org
Subject: Re: MP JWT propagation specification clarification

> On Feb 27, 2019, at 10:11 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>
> My  understanding is:
>
> ·         If the JWT only have the required custom claim groups and let's say  we have in this one "group1", "group2", "group3", it means that, if no mapping is provided,
> the entity represented by the jwt has the roles "group1", "group2", "group3". Is it right ?

Correct.

> ·         In the spec, §4.2 Additional Claims, we may have a new custom claim "roles" (example provided at page 12 "auditor", "administrator").
> It means that the entity represented by the jwt has the roles "auditor" and "administrator" and  belongs to the groups "red-group","green-group","admin-group".
> Is it right ?

This is not specified.  The long and short is we (MP-JWT spec group) couldn't agree on if the claim in the token should be called 'roles' or 'groups'.  We opted for 'group' with the intent to provide some flexibility to the implementation.  To your question below, the implementation in TomEE uses the 'groups' as the roles and there is no way to specify additional mapping in the server itself.  Currently, you'd have to do that in the app (or contribute some functionality so it's done in the server).

Were that functionality to exist, your interpretation is certainly one mode we could use.  Really there are only two logical modes (theoretically)

 - Take the explicitly mapped roles, don't add the "implicit" roles (groups)
 - Take the explicitly mapped roles, add them on top of the "implicit" roles

Coming back to the "4.2 Additional Claims" section.  I wrote that particular section (Scott wrote most the main chapters) wanting to put a stake in the sand that this may show up in a future revision of the spec.  Given the thoughts above, probably what would make the most sense is to implement something and see how it goes, then come back to the MP JWT spec with a proposal.

If you had to chose, which policy above would you want?


-David


>
> BTW, how and where to declare the groups and roles mapping in TomEE ?  in openejb-jar.xml ? other location ?
>
> Best Regards.
> ________________________________
> This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

Re: MP JWT propagation specification clarification

[David Blevins <da...@gmail.com>]

> On Feb 27, 2019, at 10:11 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
> 
> My  understanding is:
> 
> ·         If the JWT only have the required custom claim groups and let's say  we have in this one "group1", "group2", "group3", it means that, if no mapping is provided,
> the entity represented by the jwt has the roles "group1", "group2", "group3". Is it right ?

Correct.

> ·         In the spec, §4.2 Additional Claims, we may have a new custom claim "roles" (example provided at page 12 "auditor", "administrator").
> It means that the entity represented by the jwt has the roles "auditor" and "administrator" and  belongs to the groups "red-group","green-group","admin-group".
> Is it right ?

This is not specified.  The long and short is we (MP-JWT spec group) couldn't agree on if the claim in the token should be called 'roles' or 'groups'.  We opted for 'group' with the intent to provide some flexibility to the implementation.  To your question below, the implementation in TomEE uses the 'groups' as the roles and there is no way to specify additional mapping in the server itself.  Currently, you'd have to do that in the app (or contribute some functionality so it's done in the server).

Were that functionality to exist, your interpretation is certainly one mode we could use.  Really there are only two logical modes (theoretically)

 - Take the explicitly mapped roles, don't add the "implicit" roles (groups)
 - Take the explicitly mapped roles, add them on top of the "implicit" roles

Coming back to the "4.2 Additional Claims" section.  I wrote that particular section (Scott wrote most the main chapters) wanting to put a stake in the sand that this may show up in a future revision of the spec.  Given the thoughts above, probably what would make the most sense is to implement something and see how it goes, then come back to the MP JWT spec with a proposal.

If you had to chose, which policy above would you want?


-David


> 
> BTW, how and where to declare the groups and roles mapping in TomEE ?  in openejb-jar.xml ? other location ?
> 
> Best Regards.
> ________________________________
> This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.