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.