Access Control Concepts
The Warp 10 platform provides base bricks to integrate it into your authentication system. Access control for updating and reading data is achieved through the use of cryptographic tokens. Access Control is a built-in security feature that cannot be deactivated in Warp 10.
Tokens are delivered with the TOKENGEN command. Roles (owner, producer and application) are used to define the right level of data access.
Data is produced by a producer for an owner by an application. Owner and Producer are 128 bits UUIDs* HHHHHHHH-HHHH-HHHH-HHHH-HHHHHHHHHHHH. Application is a
STRING. Data is consumed by an owner within an application. The consuming owner is sometimes identified as the "billed user". There are special labels in Geo Time Series:
The Producer/Owner/Application trio allows data sharing. A data owner can allow a third party to access its data. Such sharing is done via the creation of tokens with specific values. It's possible to track data consumption via Sensision metrics and issue billing.
The data producer is identified by an UUID. He have the responsibility of pushing data onto the Warp 10 platform with a write token.
Data stored onto Warp 10 platform belongs to an UUID. It can be the same as the producer UUID or not.
Application is a logical container for a Geo Time Series, commonly applications belongs to one producer. Eventually, several producer can push data for one application name. Application is identified by any valid UTF-8 string name.
Keep in mind, An application name is unique on one Warp 10 cluster (standalone or dist).
With this following users
- Owner 1: 151de7ae-835b-4d76-b41f-4b77532097cc
- Producer: 78bdb94b-2293-4b95-a0df-70959214cfe3
- Application: app.example.name
- Writes GTS inside the application app.example.name for the owner 1 151de7ae-835b-4d76-b41f-4b77532097cc by the producer 78bdb94b-2293-4b95-a0df-70959214cfe3
- The Owner 1 151de7ae-835b-4d76-b41f-4b77532097cc can read all GTS of the application app.example.name written by 78bdb94b-2293-4b95-a0df-70959214cfe3
- Writes GTS inside the application app.example.name for and by the producer 78bdb94b-2293-4b95-a0df-70959214cfe3
- This token is also used as application token for delete GTS' contained by the application.
- The Producer 78bdb94b-2293-4b95-a0df-70959214cfe3 can read all GTS of the application app.example.name stored for himself.
All interactions with the platform which involve data rely on the use of tokens for authorization.
There are two basic types of tokens, Write Tokens for pushing data and Read Tokens for reading data.
Tokens are protected by a cryptographic envelope which ensures their integrity and authenticity.
Every token has an expiration date after which it can no longer be used. This allows to create short-lived tokens for performing specific manipulations.
Any access to stored data mandates the use of a Read Token.
All Read Tokens contain the following information:
- The name of the application accessing the data
- A list of applications whose data can be accessed (usually limited to a single application)
- A list of data owners whose data can be accessed (also usually limited to a single owner)
- A list of the data producers who pushed the data to be accessed (also usually limited to a single value)
Write Tokens are needed to push data onto the Warp 10 Platform. A Write Token bears the name of the app pushing the data (and hence the app the data will be part of), the id of the producer of the data and finally the id of the owner of the data.
Data are always write by one producer for one owner within one application.
See Token Management
As soon as you suspect a token leak, you can revoke them in a TRL (Token Revocation List). Read this page for more information.
Token role in GTS storage
The Master GTS tutorial explains in detail the interaction between tokens and GTS storage.
We also talk about tokens on the blog.