Bearer token in request classification #241
Description
Description
NeoFS service applications are middleware between users and native NeoFS protocol. All NeoFS 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. NeoFS 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 NeoFS 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 NeoFS 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 NeoFS 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[Panel.NeoFS] o--o|Bearer token| B[REST Gateway]
B o--o|Session token| C[NeoFS Node]
B o--o|Bearer token| C[NeoFS 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:
- consider token signer as request owner,
- 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:
- Consider token signer as request sender,
- Do not process extended ACL table in token body, use container ACL
- 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