Unknown Claims: Allow or Deny?

4 views
Skip to first unread message

Derek Weitzel

unread,
Oct 30, 2018, 6:09:15 PM10/30/18
to SciTokens Discussion, Jason Patton
The python scitokens library has had this enforcer policy:

> When testing a token for access, if the token has a claim that the enforcer does not know how to handle, deny the token.

The logic is that the unknown claim could “limit” the capabilities of the token further than the enforcer knows how to handle.

Should this logic continue? We noticed this issue because there are tokens with “cid” (client id) claim that the enforcer in the library does not know about.

-Derek




Jeff Gaynor

unread,
Oct 30, 2018, 6:31:56 PM10/30/18
to dis...@scitokens.org
On 10/30/2018 05:09 PM, Derek Weitzel wrote:
> The python scitokens library has had this enforcer policy:
>
>> When testing a token for access, if the token has a claim that the enforcer does not know how to handle, deny the token.
> The logic is that the unknown claim could “limit” the capabilities of the token further than the enforcer knows how to handle.

How could this be? Are you saying that your library should be vetting
all claims? That seems to be a tall order (standard OAuth is to just
ignore anything you don't recognize.)

Standard in JWT is to sign tokens to ensure that the contents are
verified and can be trusted.  So are you saying that this is
insufficient? That seems somehow wrong that the contents of the JWT
still can't be trusted after it is signed, or am I missing something? 
Why even use signing if that is the case?

Derek Weitzel

unread,
Oct 31, 2018, 2:02:33 PM10/31/18
to Jeff Gaynor, dis...@scitokens.org
Hi Jeff,

I think this policy made more sense before versioning and when (if) we were thinking about SciToken delegation or down-scoping.

This has nothing to do with signing of the token. This is all about the resource making sure it understands the permissions that the token gives the user.

Brian probably has a better example in mind, but here’s the scenario I thought of when I saw this policy:

The token has 2 attributes we care about:
scope = “read:/“
root = “/cms/data”

If the CMS issuer creates and signs this token, the issuer could believe that the token allows for the reading of data in the “/“ directory, but under the root of “/cms/data”. In this case, the resource better understand that the token allows only the reading of files under the normalized directory of “/cms/data”, not “/“.

Now this isn’t a great example, since you could normalize the path to scope = “read:/cms/data”, but then again, we may not control all issuers. They can make up whatever claims they want. The resources in this example better know how to understand the scope and “root” claims.

A similar example could be if we added delegated scitokens, which would embed the original token. You would want the enforcer to understand how to read the original token and make sure that the new token doesn’t “increase” the capabilities of the original. But this would now be handled with versions, likely. Or profiles, as Brian mentioned a while ago.

- Derek
> --
> You received this message because you are subscribed to the Google Groups "SciTokens Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@scitokens.org.




-Derek




Jeff Gaynor

unread,
Oct 31, 2018, 4:25:50 PM10/31/18
to dis...@scitokens.org
On 10/31/2018 01:00 PM, Derek Weitzel wrote:
> Hi Jeff,
>
> I think this policy made more sense before versioning and when (if) we were thinking about SciToken delegation or down-scoping.
>
> This has nothing to do with signing of the token. This is all about the resource making sure it understands the permissions that the token gives the user.

Issuer = what creates the SciToken
Service = where the SciToken is used


I think this discussion is about resolving the locus of control issue,
viz., is there a single, definitive source for permissions? If so, 
issuers are not it, though they may poll it.  So the short answer is
that it is up to the service to make sense of it, not the issuer to be
definitive.

For instance, the issuer, I, says "user U came to us, and these are the
permissions they want." Service S then looks at its access control
policies and decides. If S completely changes its policies, it is up to
S to tell I. If I does not tell S, that is not I's problem.  In this
case, I could be issuing complete garbage if S doesn't tell it
otherwise. Not optimal in that case, but this leaves it up to S to keep
everything up to date.

We have thought about similar issues with OA4MP. In the OAuth code there
are a bunch of ways of polling LDAP, HTTP Headers, databases or whatever
which are supposed to be the authoritative public permission sources S
grants us access to. This means there is a trust relationship between I
and S and the signing ensures the right folks are talking to each other,
again with the proviso that that is what we had when the token was
issued, but the service is always responsible for making sense of it at
the time it is used.


> Brian probably has a better example in mind, but here’s the scenario I thought of when I saw this policy:
>
> The token has 2 attributes we care about:
> scope = “read:/“
> root = “/cms/data”
>
> If the CMS issuer creates and signs this token, the issuer could believe that the token allows for the reading of data in the “/“ directory, but under the root of “/cms/data”. In this case, the resource better understand that the token allows only the reading of files under the normalized directory of “/cms/data”, not “/“.
>
> Now this isn’t a great example, since you could normalize the path to scope = “read:/cms/data”, but then again, we may not control all issuers. They can make up whatever claims they want. The resources in this example better know how to understand the scope and “root” claims.

Now you are starting to talk about trust relationships among the issuers
again.  It still sounds to me like you are afraid that issuers are loose
cannons. My point about signing the token relates to trusting that the
issuer did indeed fulfil its contract. If you don't trust them in the
first place, there is no reason for signing at all, is there? All that
means is you are securely talking to your attacker...

> A similar example could be if we added delegated scitokens, which would embed the original token. You would want the enforcer to understand how to read the original token and make sure that the new token doesn’t “increase” the capabilities of the original. But this would now be handled with versions, likely. Or profiles, as Brian mentioned a while ago.

Since I am unclear on how delegation would work, I cannot address that.
Has someone thought about what delegation means? Until we have nailed
down what that means we can't fruitfully discuss this further.
> - Derek
>
>
>
>> On Oct 30, 2018, at 5:31 PM, Jeff Gaynor <gay...@illinois.edu> wrote:
>>

Derek Weitzel

unread,
Oct 31, 2018, 5:58:17 PM10/31/18
to Jeff Gaynor, dis...@scitokens.org
For the record, I think we should allow unknown claims in tokens. For one reason, it makes the administration of services much easier! And makes development a bit easier.

But I can see arguments either way.

On Oct 31, 2018, at 3:25 PM, Jeff Gaynor <gay...@illinois.edu> wrote:
>
> On 10/31/2018 01:00 PM, Derek Weitzel wrote:
>> Hi Jeff,
>>
>> I think this policy made more sense before versioning and when (if) we were thinking about SciToken delegation or down-scoping.
>>
>> This has nothing to do with signing of the token. This is all about the resource making sure it understands the permissions that the token gives the user.
>
> Issuer = what creates the SciToken
> Service = where the SciToken is used
>
>
> I think this discussion is about resolving the locus of control issue, viz., is there a single, definitive source for permissions? If so, issuers are not it, though they may poll it. So the short answer is that it is up to the service to make sense of it, not the issuer to be definitive.

Right, the service has to make sense of the token given to it. But, if the token has claims it doesn’t understand, should the service deem that token “not-understood”, or should it allow unknown claims?

>
> For instance, the issuer, I, says "user U came to us, and these are the permissions they want." Service S then looks at its access control policies and decides. If S completely changes its policies, it is up to S to tell I. If I does not tell S, that is not I's problem. In this case, I could be issuing complete garbage if S doesn't tell it otherwise. Not optimal in that case, but this leaves it up to S to keep everything up to date.

I’m a bit confused. The token doesn’t say “what the user asked for,” it says “what permissions the user has received from issuer.” But the issue is not the access policies of the service, it’s the service making sure it fully understands the token.

>
> We have thought about similar issues with OA4MP. In the OAuth code there are a bunch of ways of polling LDAP, HTTP Headers, databases or whatever which are supposed to be the authoritative public permission sources S grants us access to. This means there is a trust relationship between I and S and the signing ensures the right folks are talking to each other, again with the proviso that that is what we had when the token was issued, but the service is always responsible for making sense of it at the time it is used.

I’m a bit confused by this. The service is suppose to put in some DB (or LDAP?) what permissions are allowed? I thought the point of distributed verification is that the issuers and services do not have to have close coordination. Maybe I’m not understanding this paragraph

>
>> Brian probably has a better example in mind, but here’s the scenario I thought of when I saw this policy:
>>
>> The token has 2 attributes we care about:
>> scope = “read:/“
>> root = “/cms/data”
>>
>> If the CMS issuer creates and signs this token, the issuer could believe that the token allows for the reading of data in the “/“ directory, but under the root of “/cms/data”. In this case, the resource better understand that the token allows only the reading of files under the normalized directory of “/cms/data”, not “/“.
>>
>> Now this isn’t a great example, since you could normalize the path to scope = “read:/cms/data”, but then again, we may not control all issuers. They can make up whatever claims they want. The resources in this example better know how to understand the scope and “root” claims.
>
> Now you are starting to talk about trust relationships among the issuers again. It still sounds to me like you are afraid that issuers are loose cannons. My point about signing the token relates to trusting that the issuer did indeed fulfil its contract. If you don't trust them in the first place, there is no reason for signing at all, is there? All that means is you are securely talking to your attacker…

Issuers are kinda loose canons. We won’t control all of the issuers, or all of the services.

I suppose this is more like: "is the issuer and service speaking the same “language” in the claims". This should be mostly solved by versioning though.

- Derek



-Derek




Jeff Gaynor

unread,
Nov 2, 2018, 12:00:03 PM11/2/18
to Derek Weitzel, dis...@scitokens.org
I am at a conference but will be at the meeting today if people want to
discuss this.

Jeff

Derek Weitzel

unread,
Nov 5, 2018, 11:00:41 AM11/5/18
to Jeff Gaynor, dis...@scitokens.org
I spoke with Brian. He reminded me that we had documented the validation behavior:

- All claims MUST be considered valid by the entity performing validation. If there are any unknown claims attributes - or claim values that cannot be validated - the entire token must be considered INVALID. A token must be considered completely valid or invalid.

(Bottom of the page https://scitokens.org/technical_docs/Verification)

Since it was documented this way, the python library was implemented this way.

But, this should be a good reason to have a SciTokens v2. We should start putting the version in the token itself, and if ver = “2.0”, then we should allow unknown claims. But we should have a very good list of claims that are required to be validated, much like we have now on the website.

-Derek

Brian Bockelman

unread,
Nov 5, 2018, 1:54:14 PM11/5/18
to Jeff Gaynor, dis...@scitokens.org


Sent from my iPhone

> On Oct 30, 2018, at 5:31 PM, Jeff Gaynor <gay...@illinois.edu> wrote:
>
>> On 10/30/2018 05:09 PM, Derek Weitzel wrote:
>> The python scitokens library has had this enforcer policy:
>>
>>> When testing a token for access, if the token has a claim that the enforcer does not know how to handle, deny the token.
>> The logic is that the unknown claim could “limit” the capabilities of the token further than the enforcer knows how to handle.
>
> How could this be? Are you saying that your library should be vetting all claims? That seems to be a tall order (standard OAuth is to just ignore anything you don't recognize.)
>
> Standard in JWT is to sign tokens to ensure that the contents are verified and can be trusted. So are you saying that this is insufficient? That seems somehow wrong that the contents of the JWT still can't be trusted after it is signed, or am I missing something? Why even use signing if that is the case?
>

The logic is simple - in standard OAuth usage, the issuer is also the verifier. Hence, it’s likely that, for authorization decisions, the issuer has a good idea which claims are safe to ignore. This is not true in SciTokens case - the resource server has to interpret the meaning of the issuer. The unknown claim from the issuer may have very significant impact on the authorization decision the resource server is supposed to make.

As Derek mentioned, the way we resolved this for the WLCG document is we have a list of required claims for a given version number. Then, as long as the resource server supports that version, we know that any other claims are safe to ignore.

This handling of unknown claims and the proposed change in audience semantics (to allow “any”) is sufficient in my mind to cut v2 of the profile.

Brian

>
>>
>> Should this logic continue? We noticed this issue because there are tokens with “cid” (client id) claim that the enforcer in the library does not know about.
>>
>> -Derek
>>
>>
>>
>>
>
Reply all
Reply to author
Forward
0 new messages