Provide a definition of wlcg.groups that is independent of VOMS. #15
Conversation
|
Thanks, do you know whether it's possible to fix the link? |
|
I think I fixed it? |
|
Hi all, |
I can drop this onto the agenda for the 16th now |
|
|
||
| Relying parties MUST only consider the group membership asserted in the token for authorization decisions. Particularly, membership in a child group (`/cms/uscms`) does not implicitly imply membership in the parent group (`/cms`) unless the parent group is explicitly listed in the token. | ||
|
|
||
| The token does not need to list all groups the user has access to; relying parties MUST utilize only the asserted groups in the implied order. The `wlcg.groups` claim is optional and may either be empty or not provided at all. The user may provide input on the contents and ordering of this claim; this is covered [below](#scope-based-attribute-selection). |
There was a problem hiding this comment.
The token does not need to list all groups the user has access to
I may have missed past discussions, but what is the rationale? What problem are you trying to solve wrt to the status quo?
In any case, the section "Scope-based Group Selection" would also need to be rewritten.
There was a problem hiding this comment.
The rationale would be that tokens can/should be made as lean as possible to:
- mitigate potential concerns about their sizes (there could be a large number of groups);
- do not bring contents that are totally irrelevant to the authZ decision (but have to be parsed, forwarded and logged nonetheless).
There was a problem hiding this comment.
It sounds as premature optimization to me, but at least it's clear now. This requires changes in the token issuer, that's why I asked to rewrite also the following section.
|
|
||
| Relying parties MUST only consider the group membership asserted in the token for authorization decisions. Particularly, membership in a child group (`/cms/uscms`) does not implicitly imply membership in the parent group (`/cms`) unless the parent group is explicitly listed in the token. |
There was a problem hiding this comment.
Relying parties MUST only consider the group membership asserted in the token for authorization decisions
This sentence seems to rule out AuthZ decisions based on "scope"-claim values ("MUST only consider ... for authz decisions")
I think what you meant to say is something like:
Relying parties MAY consider the subject as being a member of the various groups asserted by the
token; however, such relying parties MUST NOT infer membership of any other groups that are not
asserted by the OP.
Like this, I don't think you need the specific example.
There was a problem hiding this comment.
Reformulating that a bit you can keep the original meaning (i.e. keeping the authZ decisions), but using your negative (MUST NOT) which is indeed better:
For authorization decisions relying parties MUST NOT consider any group memberships that are not
asserted by the OP in the token.
Consolidation of several changes based on: #15, comments therein plus minor further adjustments.
|
Hi all, |
|
Superseded by #46 . |
This is a replacement for #2; it removes the text about implicit authorizations and makes a strong requirement for explicit-only group authorization.