In-Flight Masking Authentication and Permissions
Introduction
In-flight masking endpoints are authenticated using JSON Web Tokens (JWTs).
A JWT is generated by sending credentials
to /api/auth/jwt/login/ and a JWT is returned.
After receiving a token, it should be used in the Authorization header to authenticate requests,
preceded by the word Bearer and a space.
Fetching and using JWTs
Refer to /api/auth/jwt/login/ for instructions on generating a JWT.
In summary, POST a username and password to the endpoint, and receive a JWT token and refresh token.
The JWT is valid for 12 hours, and the refresh token is valid for 24 hours.
When the JWT expires,
the refresh token can be posted to /api/auth/jwt/refresh/
to receive a new JWT with expiry in another 12 hours.
However, the refresh token itself is only active for 24 hours,
and can not be renewed.
Single Sign-On Authentication
Single sign-on (SSO) users are not able to authenticate and receive JWTs, so in-flight masking is not available to SSO users. This includes both the web interface and the masking API.
Permissions
The actions available to the user are controlled by their role. These permissions apply to both the web interface and the REST API.
| Action | Admin | Mask Builder | Mask Runner |
|---|---|---|---|
| View the list of ruleset plans | Yes | Yes | Yes |
| Create, update and delete ruleset plans | Yes | Yes | No |
| Fetch ruleset plan details | Yes | Yes | No |
| Mask data by POSTing to a masking endpoint | Yes | Yes | Yes |
In the web interface, Mask Runners can see the In-Flight Masking list page but cannot access the editor or perform any create, edit, or delete actions.
The user's role is embedded in the JWT when it is created. Therefore, if a user's role is updated through the DataMasque admin frontend, a new JWT must be generated and used for the role change to take effect on the in-flight server.