Evgenii Stratonikov
7bc3003803
This is about authentication only and eACL is deprecated, so only mention `allow_impersonate` flag. Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>
2.9 KiB
Authentication and signatures
General overview
Signatures
Every message in the FrostFS network is signed. Each signature consists of:
- Scheme
- Public key
- Signature
If signature check fails, operation is aborted and the error is returned to the user.
Schemes
Currently, 3 schemes are defined in the frostfs-api:
ECDSA
Defined in section 6 of FIPS 186. Implemented in the Go stdlib. This is the primary algorithm used to sign and verify requests. The hash algorithm used is SHA-512.
RFC6979
RFC 6979 defines deterministic algorithm for ECDSA signatures. It it used primarily used by neo-go and allows us to perform signature checks inside the contract, such as for container. The hash algorithm used is SHA-256
Public key
ECDSA public key corresponding to the private key being used to sign a message. It is the primary user identity and is used to determine the request originator.
Tokens
Generally, the request owner, i.e. an account all access control checks are applied to is taken from the request signature. However, session and bearer tokens can alter authentication process by making "effective" request owner differ from the actual one. The general scheme is given by the following picture:
It is important to note, that the token is only valid when the request signature corresponds to the actor token is issued to.
Session token
Session token can override the rules of determining request owner. It is defined in the frostfs-api. If user A signs a session token for user B, then user B can sign request with its own key, while the node will still process the request as if it was originated from user A. This is used, for example, when putting objects in system:
- User creates a session with node, recevieving session token.
- User signs session token for a freshly generated key, stored on a storage node.
- User sends raw stream of bytes, while the node signs created objects with the session key. This way other nodes can validate the object owned by user, even though it is signed by a different key.
Session token may have some restrictions:
- Lifetime, effectively an epoch after which it becomes invalid.
- Set of operations it applies to.
- The entity it is given to. This is provided in
session_keyfield containing the public key.
Bearer token
Bearer token is generally used for access control but can also affect authentication if allow_impersonate flag is set. With this flag it behaves similarly to session token.