TrueCloudLab/frostfs-api
25
0
Fork 14
Code Issues 10 Pull requests Releases Activity Actions

Bearer token in request classification #18

New issue
Closed
opened 2023-04-07 14:15:00 +00:00 by alexvanin · 1 comment
alexvanin commented 2023-04-07 14:15:00 +00:00
Owner
Copy link

Description

FrostFS service applications are middleware between users and native FrostFS protocol. All FrostFS requests are signed with the key. Service applications do not have access to user's keys, so they use configured keys (middleware keys) to sign requests.

In general, public key is used to identify request sender (owner) to apply access control rules. FrostFS supports token mechanism to allow access to the requests signed by middleware keys: bearer tokens and session tokens.

In the request handler, storage node fetches public key and compares it with container owner, alphabet or container nodes. Here is the simplified scheme of fetch function from v0.32.0 release: RequestOwner().

flowchart LR
    A[Start] --> B{Is session\ntoken present?}
    B -->|Yes| C[Owner == Session token creator]
    B -->|No| D[Owner == Request sender]
    C --> E[End]
    D --> E

There are two cases where token scheme is not applicable.

1. Service application requires access to a private container on behalf of the user

WebUI + REST gateway should provide UX similar to CLI. To access private container, REST Gateway's request should be considered as user's request. The only way to impersonate user is to use session token signed by user's key.

However, session token can't be reused for different requests: object context requires verb and object address.

Session token is a nice solution for peer-to-peer communication, when application uses private key to resign session token for every request. It is not applicable for service application, because token usually is signed once in a while:

  • signing every request might be very bad UX (e.g. with Wallet Connect),
  • session token is not transitive, so the user has to create session with unknown FrostFS storage node, instead of the known gateway.

2. User grants access to the container, which is accessed through gateway

S3 gateway user wants to provide object access for specific user. To do that, container's extended ACL is modified to grant access for user's public key.

When S3 gateway sends request on behalf of granted user, access control record can't be matched, because S3 signed request with middleware key.

Session token is a nice solution for peer-to-peer communication, when client uses private key to resign session token for evert request.

It is not applicable for service application, because token usually is signed once for a while:
- signing every FrostFS request might be very bad UX (e.g. with Wallet Connect),
- session token is not transitive, so the client has to create session with unknown FrostFS Node, instead of the known gateway.

Service applications usually work with bearer tokens, while session is established between gateway and the node.

flowchart LR
    A[Web App] o--o|Bearer token| B[REST Gateway]
    B o--o|Session token| C[FrostFS Node]
    B o--o|Bearer token| C[FrostFS Node]

Private container denies bearer tokens. So service application have to create public containers with restricted extended ACL to imitate private container.

Proposal

To solve this issue, modify bearer token processing behaviour. Provide impersonate flag in the token body.

message BearerToken {
  message Body {
    EACLTable eacl_table = 1 [json_name="eaclTable"];
    neo.fs.v2.refs.OwnerID owner_id = 2 [json_name="ownerID"];
    message TokenLifetime {
      uint64 exp = 1 [json_name="exp"];
      uint64 nbf = 2 [json_name="nbf"];
      uint64 iat = 3 [json_name="iat"];
    }
    TokenLifetime lifetime = 3 [json_name="lifetime"];
+   bool allow_impersonate = 4;
  }
  Body body = 1 [json_name="body"];
  neo.fs.v2.refs.Signature signature = 2 [json_name="signature"];
}

On false (default), behaviour is the same.

On true:

  1. consider token signer as request owner,
  2. do not process extended ACL table in token body.

When token allows impersonating, there is no meaning in replacing container extended ACL table with token extended ACL table. Node should behave as the request was originally signed by token owner. Then S3 Gateway users will be able to provide object access to specific users.

flowchart LR
    A[Start] --> F{Is bearer\ntoken present?}
    F -->|Yes|G{Impersonate?}
    G -->|Yes|H[Owner == Bearer token creator]

    F -->|No| B{Is session\ntoken present?}
    G -->|No| B
    B -->|Yes| C[Owner == Session token creator]
    B -->|No| D[Owner == Request sender]

    C --> E[End]
    D --> E
    H --> E

flowchart LR
    A[Start] --> F{Is bearer\ntoken present?}
    F -->|Yes| G{Impersonate?}
    F -->|No| B[Check container extended ACL]
    G -->|Yes| B
    G -->|No| C[Check bearer token extended ACL]

Tree service

Changes above are applied for object service. However, tree service is also affected by this change.

On false (default), behaviour is the same.

On true:

  1. Consider token signer as request sender,
  2. Do not process extended ACL table in token body, use container ACL
  3. Do not require token issuer to be container owner.

(3) looks very important here. Now S3 Gateway accesses user bucket by attaching bearer token. To access other user buckets it does not attach bearer token, because token issuer is always going to be different from container owner.

To grant access to the container, S3 gateway will specify public key of the user in container extended ACL. To match this rule, S3 gateway has to attach bearer token with impersonate flag. So token issuer check should gone in this case. It makes sense, because impersonate flag can be treated as if "there is no bearer tokens at all, request is signed on behalf of token issuer".

🟢 It is backward compatible
🔴 Classification becomes less clear

# Description FrostFS service applications are middleware between users and native FrostFS protocol. All FrostFS requests are signed with the key. Service applications do not have access to user's keys, so they use configured keys (middleware keys) to sign requests. In general, public key is used to identify request sender (owner) to apply access control rules. FrostFS supports token mechanism to allow access to the requests signed by middleware keys: bearer tokens and session tokens. In the request handler, storage node fetches public key and compares it with container owner, alphabet or container nodes. Here is the simplified scheme of fetch function from v0.32.0 release: [RequestOwner()](https://git.frostfs.info/TrueCloudLab/frostfs-node/src/commit/ee7468daa73fe6230a5aa165506710ba2dca1f96/pkg/services/object/acl/v2/request.go#L111). ```mermaid flowchart LR A[Start] --> B{Is session\ntoken present?} B -->|Yes| C[Owner == Session token creator] B -->|No| D[Owner == Request sender] C --> E[End] D --> E ``` There are two cases where token scheme is not applicable. ### 1. Service application requires access to a private container on behalf of the user WebUI + REST gateway should provide UX similar to CLI. To access private container, REST Gateway's request should be considered as user's request. The only way to impersonate user is to use session token signed by user's key. However, session token can't be reused for different requests: object context requires [verb](https://git.frostfs.info/TrueCloudLab/frostfs-api/src/commit/cbc038f84e7e8bf398bcc03ab53527c6b8cd18d1/session/types.proto#L41) and [object address](https://git.frostfs.info/TrueCloudLab/frostfs-api/src/commit/cbc038f84e7e8bf398bcc03ab53527c6b8cd18d1/session/types.proto#L52). Session token is a nice solution for peer-to-peer communication, when application uses private key to resign session token for every request. It is not applicable for service application, because token usually is signed once in a while: - signing every request might be very bad UX (e.g. with Wallet Connect), - session token is not transitive, so the user has to create session with unknown FrostFS storage node, instead of the known gateway. ### 2. User grants access to the container, which is accessed through gateway S3 gateway user wants to provide object access for specific user. To do that, container's extended ACL is modified to grant access for user's public key. When S3 gateway sends request on behalf of granted user, access control record can't be matched, because S3 signed request with middleware key. Session token is a nice solution for peer-to-peer communication, when client uses private key to resign session token for evert request. It is not applicable for service application, because token usually is signed once for a while: - signing every FrostFS request might be very bad UX (e.g. with Wallet Connect), - session token is not transitive, so the client has to create session with unknown FrostFS Node, instead of the known gateway. Service applications usually work with bearer tokens, while session is established between gateway and the node. ```mermaid flowchart LR A[Web App] o--o|Bearer token| B[REST Gateway] B o--o|Session token| C[FrostFS Node] B o--o|Bearer token| C[FrostFS Node] ``` Private container denies bearer tokens. So service application have to create public containers with restricted extended ACL to imitate private container. # Proposal To solve this issue, modify bearer token processing behaviour. Provide *_impersonate_* flag in the token body. ```diff message BearerToken { message Body { EACLTable eacl_table = 1 [json_name="eaclTable"]; neo.fs.v2.refs.OwnerID owner_id = 2 [json_name="ownerID"]; message TokenLifetime { uint64 exp = 1 [json_name="exp"]; uint64 nbf = 2 [json_name="nbf"]; uint64 iat = 3 [json_name="iat"]; } TokenLifetime lifetime = 3 [json_name="lifetime"]; + bool allow_impersonate = 4; } Body body = 1 [json_name="body"]; neo.fs.v2.refs.Signature signature = 2 [json_name="signature"]; } ``` On *_false_* (default), behaviour is the same. On *_true_*: 1) consider token signer as request owner, 2) do not process extended ACL table in token body. When token allows impersonating, there is no meaning in replacing container extended ACL table with token extended ACL table. Node should behave as the request was originally signed by token owner. Then S3 Gateway users will be able to provide object access to specific users. ```mermaid flowchart LR A[Start] --> F{Is bearer\ntoken present?} F -->|Yes|G{Impersonate?} G -->|Yes|H[Owner == Bearer token creator] F -->|No| B{Is session\ntoken present?} G -->|No| B B -->|Yes| C[Owner == Session token creator] B -->|No| D[Owner == Request sender] C --> E[End] D --> E H --> E ``` ```mermaid flowchart LR A[Start] --> F{Is bearer\ntoken present?} F -->|Yes| G{Impersonate?} F -->|No| B[Check container extended ACL] G -->|Yes| B G -->|No| C[Check bearer token extended ACL] ``` ### Tree service Changes above are applied for object service. However, tree service is also affected by this change. On *_false_* (default), behaviour is the same. On *_true_*: 1) Consider token signer as request sender, 2) Do not process extended ACL table in token body, use container ACL 3) Do not require token issuer to be container owner. (3) looks very important here. Now S3 Gateway accesses user bucket by attaching bearer token. To access other user buckets it does not attach bearer token, because token issuer is always going to be different from container owner. To grant access to the container, S3 gateway will specify public key of the user in container extended ACL. To match this rule, S3 gateway has to attach bearer token with impersonate flag. So token issuer check should gone in this case. It makes sense, because impersonate flag can be treated as if "there is no bearer tokens at all, request is signed on behalf of token issuer". --- :green_circle: It is backward compatible :red_circle: Classification becomes less clear
dkirillov was assigned by alexvanin 2023-04-07 14:15:00 +00:00
realloc added this to the v2.15 - Karpinsky Ice Cap milestone 2023-04-09 18:52:40 +00:00
alexvanin commented 2023-04-13 06:47:28 +00:00
Author
Owner
Copy link

realloc added this to the v2.15 milestone 3 days ago

It's more like v2.16, in my opinion. v2.15 should be closed because there is neofs-api-go v2.15 which is related to some commit from master branch already.

/cc @fyrchik @realloc

> realloc added this to the v2.15 milestone 3 days ago It's more like v2.16, in my opinion. v2.15 should be closed because there is [neofs-api-go v2.15](https://git.frostfs.info/TrueCloudLab/frostfs-api-go/src/tag/v2.15.0) which is related to some commit from master branch already. /cc @fyrchik @realloc
👍 2
fyrchik modified the milestone from v2.15 - Karpinsky Ice Cap to v2.17 - Zemu Glacier 2023-04-13 13:10:49 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
rebranding
No results found.
Labels
Clear labels   
P0

Highest

  
P1

High

  
P2

Medium

  
P3

Low

  
good first issue

Good for newcomers

  
triage

Needs to be triaged

  
Infrastructure

Infrastructure, Automation, CI/CD or DevOps related stuff

  
blocked

The issue or PR is blocked by something

  
bug

Something is not working

  
config

Configuration format update or breaking change

  
discussion

Talking about something in order to reach a decision or to exchange ideas

  
documentation

Documentation related

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
go

Language features adoption

  
help wanted

Extra attention is needed

  
internal

   
invalid

Something is wrong

  
kludge

This is a kludge and we know it

  
observability

Related to metrics, tracing and logs

  
perfomance

Perfomance related

  
question

More information is needed

  
refactoring

Refactoring

  
wontfix

This won't be fixed

No labels
P0
P1
P2
P3
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
Milestone
Clear milestone
No items
No milestone
v2.17 - Zemu Glacier
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
dkirillov
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-api#18
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?