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 all commits
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
53 changes: 16 additions & 37 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,41 +5,17 @@ _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 | Changes scope of storage.stage and storage.read capabilities

# Introduction

This document describes how WLCG users may use the available geographically distributed resources without X.509 credentials. In this model, clients are issued with bearer tokens; these tokens are subsequently used to interact with resources. The tokens may contain authorization groups and/or capabilities, according to the preference of the VO, applications and relying parties.

Wherever possible, this document builds on existing standards when describing profiles to support current and anticipated WLCG usage. In particular, three major technologies are identified as providing the basis for this system: OAuth2 (RFC 6749 & RFC 6750), [OpenID Connect](http://openid.net/developers/specs/) and JSON Web Tokens (RFC 7519). Additionally, trust roots are established via OpenID Discovery or OAuth2 Authorization Server Metadata (RFC 8414). This document provides a profile for OAuth2 Access Tokens and OIDC ID Tokens. **The WLCG Token Profile version described by this document is “1.0”.**
Wherever possible, this document builds on existing standards when describing profiles to support current and anticipated WLCG usage. In particular, three major technologies are identified as providing the basis for this system: OAuth2 (RFC 6749 & RFC 6750), [OpenID Connect](http://openid.net/developers/specs/) and JSON Web Tokens (RFC 7519). Additionally, trust roots are established via OpenID Discovery or OAuth2 Authorization Server Metadata (RFC 8414). This document provides a profile for OAuth2 Access Tokens and OIDC ID Tokens. **The WLCG Token Profile version described by this document is “1.1”.**

The profile for the usage of JSON Web Tokens (RFC 7519) supports distributed authentication and authorization within the WLCG. The JWT profile is meant as a mechanism to transition away from the existing GSI-based (Globus) system where authentication is based on X509 proxy certificates and authorization is based on VOMS extensions and identity mapping.

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