Space Cloud provides robust access control mechanisms for securing your data.
Space Cloud provides auto generated APIs for various resources like databases, file storage, remote services, etc.
As a developer, you need to write security rules for each of the resources exposed by Space Cloud. These security rules are simple JSON objects that you can configure at a very granular level for each resource. For instance, the security rules for database module can be configured at the operation level (create, read, update and delete) for each table in your database. Checkout [configuring the security rules] to learn how security rules are configured for each module.
All incoming requests to the Space Cloud are first validated by the API controller using the security rules defined by you.
Security rules help check whether the request is authenticated and authorized. It can even modify the request/response (for data masking) before passing it on to the next stage. A request is allowed to be made only if the security rules for that resource are resolved.
Security rules help you enforce various access control mechanisms on a resource:
A simple example for granting admin users access to a resource looks like this:
{
"rule": "match",
"type": "string",
"eval": "==",
"f1": "args.auth.role", // assuming token consist of a claim named role
"f2": "admin"
}
Security rules in Space Cloud are flexible enough to enforce any access control logic. This includes querying a database or triggering a webhook for edge cases.
Check out the detailed documentation for security rules or explore some popular examples of security rules
Token based authentication is enforced for all rule types beyond
allow.
Space Cloud expects a JWT token in every incoming request. For HTTP requests, the token should be present inside Authorization header as Bearer <token>, whereas for websocket requests, the token should be present in the data.token key of the message body.
The security module in Space Cloud checks whether a token is valid or not based on the following criteria:
secrets provided to Space Cloud.exp claim), then its value should be in the future.Space Cloud considers a request to be authenticated only if it contains a valid token. Once a token is considered valid, its claims are parsed and made available in the args.auth variable to be used by security rules.
If a user tries to change any of the token claims or tries to create his/her own false token, it would fail at the verification stage because of the nature of JWTs. You can check out the official website of the JWT project to learn more about it.
If you simply want to enforce token based authentication on a resource and nothing else, you need to use the authenticated rule.
Usually a token is generated and provided by an authentication service on a successful signin/signup request by an user. These tokens are signed with a secret by the authentication service. This secret needs to be provided to Space Cloud in order for token based authentication to work.
You can either use the in-built user management module of Space Cloud as an authentication service or use a custom / third-party service.
This mechanism decides whether an authenticated user is authorized or not to make a request. The access to request is granted only if the security rule is resolved based on it’s type. Various ways to grant access are:
match rule)You can easily mix match different security rules together in Space Cloud to solve complex access control problems.
Data masking is the process of replacing/hiding parts of your data from the user or the system.
For instance, many compliances require you to encrypt all the private details of an user like email or name to be encrypted. In some use cases you might want certain sensitive parts of your data to be viewed only by an user authorized to view that.
Example: Remove the address and email fields from the response of reading profiles table if the profile is not his own:
{
"rule": "remove",
"fields": ["address", "email"],
"clause": {
"rule": "match",
"type": "string",
"eval": "==",
"f1": "args.auth.id", // assuming token consist of a claim named id that contains the user id
"f2": "args.find.id" // assuming profiles table consist of id field indicating the user of the profile
}
}
Have a technical question?
Improve the docs!