FTS wants to go with the token per (Storage, <src|dst>) approach, as opposed to a different token for each particular token.
It is the responsibility of the user to provide the appropriate credentials, similarly to how they do right now via the proxy certificate delegation.
FTS to introduce a delegation mechanism for tokens:
- Tokens will be delegated according to a (CredID, Storage, <src|dst>) tuple
- Clients will be able to delegate to "*" storage, a particular storage or (Storage, <src|dst>) pair
- The delegation endpoint will be adapted to also list a user's delegated tokens
CredID (credential ID) is a hash function of certain token fields. For the moment, that includes: "sub", "wlcg.groups" and "iss".
Should "scopes" be part of the CredID?
For convenience, FTS will provide transparent delegation via the command line tools. Example:
$ fts-rest-transfer-submit --access-token <token_for_fts> --src-token <src_token> --dst-token <dst_token> -s https://fts3-pilot.cern.ch:8446/ <src> <dst>
<token_for_fts> - created the CredID for the delegation
<src_token> - token to delegate for source storage
<dst_token> - token to delegate for destination storage
- Include "storage.*" scope in the CredID
- When does the token delegation end? Has to be defined
- we have to think a bit about this proposal
- e.g. not clear when client (e.g. Rucio) needs to delegate fresh token
- some experiments don't want to allow scope.read:/ - unable to protect any data for some subgroup
- refresh tokens are not "cheap" on IAM side
- bootstrap problem
- Petr create doodle pool
- send email to the BDT mailing list