Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarifies scope of storage.stage and storage.read #27

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Clarifies scope of storage.stage and storage.read #27

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
52195c3
Clarifies scope of storage.stage and storage.read
Jun 15, 2023
2a51685
Updates version to 1.1
Jun 19, 2023
bcf382a
Changes version message
Jun 19, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 15 additions & 36 deletions profile.md
View file
Open in desktop
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The patch forgot to update line 18 (after the patch is applied), which includes the text

The WLCG Token Profile version described by this document is “1.0”.

This should be updated to say:

The WLCG Token Profile version described by this document is “1.1”.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are going to be a lot more changes in the next released version, which I believe is likely to be version 2.0. Update of the version history shouldn't be in this PR.

Original file line number Diff line number Diff line change
Expand Up @@ -5,35 +5,11 @@ _Authored by the WLCG AuthZ Working Group_

**Version History:**


<table>
<tr>
<td><strong>Date</strong>
</td>
<td><strong>Version</strong>
</td>
<td><strong>Comment</strong>
</td>
</tr>
<tr>
<td>17.09.2019
</td>
<td>0.1
</td>
<td>Final version presented to MB
</td>
</tr>
<tr>
<td>25.09.2019
</td>
<td>1.0
</td>
<td>Version published on Zenodo
</td>
</tr>
</table>


Date | Version | Comment
-----------|---------|------------------------------
17.09.2019 | 0.1 | Final version presented to MB
25.09.2019 | 1.0 | Version published on Zenodo
15.06.2023 | 1.1 | Updates storage capabilities

# Introduction

Expand Down Expand Up @@ -441,16 +417,19 @@ We aim to define a common set of authorizations (particularly storage-related au

For a given storage resource, the defined authorizations include:



* **storage.read**: Read data. Only applies to “online” resources such as disk (as opposed to “nearline” such as tape where the **stage** authorization should be used in addition).
* **storage.read**: Read data. For “nearline” data such as tape, the **stage** authorization should be used in addition.
* **storage.create**: Upload data. This includes renaming files if the destination file does not already exist. This capability includes the creation of directories and subdirectories at the specified path, and the creation of any non-existent directories required to create the path itself (note the server implementation MUST NOT automatically create directories for a client). This authorization DOES NOT permit overwriting or deletion of stored data. The driving use case for a separate `storage.create` scope is to enable stage-out of data from jobs on a worker node.
* **storage.modify**: Change data. This includes renaming files, creating new files, and writing data. This permission includes overwriting or replacing stored data in addition to deleting or truncating data. This is a strict superset of `storage.create`.
* **storage.stage**: Read the data, potentially causing data to be staged from a nearline resource to an online resource. This is a superset of `storage.read`.

For a given computing resource, the defined authorization activities include:
* **storage.stage**: Stage the data from a nearline resource to an online resource, making the data available for access
to users bearing a token with the **storage.read** authorization. Storage Endpoints may impose additional constraints
on who is authorized to stage data.

For nearline data such as tape, the “stage+transfer” semantics are defined by the tape access protocol independently
from the authorization scheme. For XRootD, this means “prepare -s” (stage), “query prepare”, “abort prepare”, “evict”
and “copy”. For HTTP, the semantics are defined in the
[WLCG Tape REST API](https://cernbox.cern.ch/pdf-viewer/public/vLhBpHDdaXJSqwW/WLCG%20Tape%20REST%20API%20reference%20document.pdf).
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion to use the wlcg-storage/wlcg-tape-rest-api repository instead of CERNBox for the WLCG Tape REST API specification document.


For a given computing resource, the defined authorization activities include:

* **compute.read:** “Read” or query information about job status and attributes.
* **compute.modify:** Modify or change the attributes of an existing job.
Expand Down Expand Up @@ -480,7 +459,7 @@ Examples values of the `scope` claim:
* `"storage.read:/" `This would allow a job (or any bearer) to read any file owned by the VO.
* `"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`.
* `"compute.create"` This would allow the bearer to submit jobs to a batch system on behalf of the issuing VO.
* `"storage.stage:/tape/subdir storage.read:/protected/data"` This would allow the bearer to read (and possibly stage) files in `/tape/subdir` and read files in `/protected/data`.
* `"storage.stage:/tape/subdir storage.read:/tape/subdir"` This would allow the bearer to stage files in `/tape/subdir` and read the files after they have been staged.
* `"storage.read:/store storage.create:/store/mc/datasetA"` This would allow the bearer to read from `/store` and create new files (not overwriting existing data) in `/store/mc/datasetA`.


Expand Down