WLCG-AuthZ-WG/common-jwt-profile

Bad example for storage scope-based authorisation statements

Closed this issue · 3 comments

paulmillar commented

Page 13 contains several examples of scope-based authorisation along with English-language prose description of the corresponding authorisation policy. The second example is copied here:

“storage.read:/protected storage.create:/protected/subdir”​ This
would allow a job to read the VO’s data in the ​/protected​ subdirectory but
(destructively) write into ​/protected/subdir​.

This example is problematic for two reasons:

  • The use of the word "but" suggests the two AuthZ statements are somehow conflicting. Using "and" would be better: "This would allow [...] and [...]". This could be make clearer by including a second "allow" ("This would allow [...] and allow [...]"), although I think it's a matter of personal taste which of these two versions (without or with a second "allow") is better.

  • The storage.create is described as allowing the job to write destructively into /protected/subdir. This is wrong. The storage.create description (see page 12) says:

    storage.create​: [...] This authorization DOES NOT permit overwriting or deletion of stored data.

Here are two suggested replacements, depending on whether the example should demonstrate the use of storage.create or storage.modify:

  • “storage.read:/protected storage.create:/protected/subdir”​ This
    would allow a job to read the VO’s data in the ​/protected​ subdirectory and
    non=destructively write into ​/protected/subdir​.
  • "storage.read:/protected storage.modify:/protected/subdir”​ This
    would allow a job to read the VO’s data in the ​/protected​ subdirectory and
    write into ​/protected/subdir​, potentially overwriting existing data.
DrDaveD commented

Sounds right to me. Submit a pull request.

paulmillar commented

Yes, but which one? or should the pull request introduce an additional example?

DrDaveD commented

I don't think it really matters. It could include both.

In general I think it's much easier to discuss a specific proposed change than to discuss an issue in the abstract. It's also unlikely that someone other than issue creators here will volunteer to propose a change.