The Gateway (Secrets Proxy) is a centralized, custodial secrets management service, enabling easier interaction with the security components of the SxT platform. It lives outside of the platform and is not decentralized, which means it can store things like passwords, private keys, and configured user permissions. The Gateway (Secrets Proxy) is designed to act as a proxy which forwards your requests to the decentralized network on your behalf. Check out the API specs here.
You can connect to the Gateway (Secrets Proxy) using the following interfaces:
In general, secrets management is the process of storing and managing security data such as authentication credentials (e.g. password, keys, tokens) or authorization configuration (e.g. access control lists, security policies). Secrets management is a well-known best practice in the cybersecurity world to ensure safe access of protected IT resources by authenticated and authorized identities.
Inside the Space and Time platform, authentication and authorization are, by design, decentralized. Secrets such as passwords or access control lists cannot be stored in a trustless environment. In addition, the protocol by which users authenticate themselves and authorize requests to access resources cannot rely on any centralized party. Instead, each user must implement their own signature generation and biscuit management solution and ensure that this protocol matches the expectations of the platform. Some users would prefer to rely on a trusted, centralized third party to handle the secrets needed to interact with the platform. For this reason, we have built the Gateway.
One core feature of the Gateway is enabling traditional Web2-style authentication (i.e. username and password). Users can register/log in with a username and password and let the Gateway handle the actual authentication with the core SxT network on their behalf. Behind the scenes, the Gateway will use (or generate during registration) a ED25519 keypair and associate it with your user. Assuming you can authenticate with your password, the Gateway will request a challenge for your user, calculate a signature with your private key, and request access tokens from the network. In this manner, users of the Studio, JDBC driver, or even a REST client can reach out to the Gateway via one API request and proceed with platform interaction as if they had gone through the full authentication workflow with the platform.
Another feature of the Gateway is the biscuit key and permission management to support platform authorization workflows. Using the Gateway, user can configure a security policy for how the Gateway should manage private keys. When creating a new resource, users make a simple request to the proxy and it will provide a valid biscuit and public key needed to authorize the create request. After creating the resource with the proxy, users can then configure permissions on those resources for other users. These permissions are used by the Gateway to dynamically generate biscuits for users. Finally, users can even upload their own biscuits to the Gateway and later retrieve them for use.
Updated 5 days ago