In general, RavenDB assumes that an application will implement its own logic and business rules, limiting
itself to protect the data from unauthorized access. Applications operate on behalf of developers, and as such, they are in a better position than RavenDB to determine what is
allowed. This is why access levels of RavenDB databases in each cluster are highly customizable by cluster admins
Authorization Levels in Client Certificates
The security system in RavenDB does not make assumptions about which types of users should access which type of database. The concept of a user
does not really exist within RavenDB in this manner. Instead, cluster admins or operators create various client certificates and configure each one with a custom set of permissions.
- Cluster Admin
Full administrative access to clusters and databases within.
Admin access to databases, but not to modify the cluster.
Lowest levels of privileges.
- "User" certificates are configured to specify which databases people can access with each certificate.
- "User" authorization levels are also configured per database.
In most cases, users do not access RavenDB directly. Aside from admins and developers during the development process, all access to
the data inside RavenDB is expected to be done through your applications. A security mechanism on a per-user basis is not practical in complex systems
because each user (employee or customer) may need different access levels to different portions of the data.
Also, the same application usually needs to access the same data on behalf of different types of users with different levels of access.
Most organizations have fairly complex architectures. In most systems, the access level
and operations allowed are never simple enough to be able to express them as an Access Control List. They are highly dependent on business rules and
processes, the state of the system, etc.
How can authorization levels efficiently handle complex systems? By customizing access via client certificates. For example, an employee may request a vacation day, but the employee
is not permitted to approve their own vacation. The HR manager, on the other hand, may approve the vacation.
From the point of view of RavenDB, the act of editing a vacation request document or approving it looks very much the same, it's a simple document edit.
The way that a typical business system looks at those operations is often much more complicated. Perhaps the HR manager is given a client certificate with read/write permission to edit documents on the HR database,
while other employees have a certificate with read-only access. Thus, they must make requests for changes to the HR staff. Also, the HR staff should have read/write access to the HR database,
but not to development-oriented data, whereas developers might have read/write or admin permissions to relevant databases.
Meanwhile, customers likely have read/write certification to their user account, but read-only access to the catalog.
Thus, RavenDB is designed so that each client certificate has specific and customizable permissions for various databases as well as configurable authorization levels.
Full Access to Database
RavenDB expects the applications and systems using it to utilize the security infrastructure it provides to prevent unauthorized access, such as a different
application trying to access the HR database. However, once access is granted, the access is complete.
RavenDB security infrastructure operates at the level of the entire database. If you are granted access to a database, you can access
any and all documents in that database unless protection is explicitly configured.
Partial Access to Database
There are two approaches to giving partial access to a database:
Using ETL for selective, one-way data transfer
Some developers need to provide partial access to a database that also contains sensitive data. One approach is to set up an Extract, Transform, Load (ETL) task:
- Create a dedicated database that the public will be able to access.
- Generate a client certificate with "User" security clearance so that
you can configure it to give access only to the dedicated, public-facing database.
If the dedicated database is on a different cluster than the source database: (This is optional. If both databases are on the same cluster, skip to step 4.)
Then set up an ETL task from the source database to the exposed, destination database.
- After entering the script code, you can click the blue button to test the script before saving the ETL. Once you click the red Save button,
the ETL task begins to work. It will transform and add the data to the dedicated database.
- Check the dedicated database to make sure that the transform script did what you want it to do.
This database should only have the information that you filtered and is ready to expose to the public.
With this approach, you can choose exactly what is exposed, including redacting personal information, hiding details, etc. Because the ETL process is unidirectional,
this also protects the source data from modifications made to the new database. On the other hand, ETLs are ongoing tasks, so changes made to data
in the source database will be reflected automatically in the destination database.
Together, ETL and dedicated databases can be used for fine-grained filtration, but that tends to be the exception, rather than the rule.
Setting "User" Access Levels
You can also control access by giving a client certificate a User security clearance.
With this clearance, you can set a different access level to each database. The three "User" access levels are:
This approach is similar to the HR Manager and Customers certificates in the example given above.
It enables developers to control access levels by configuring client certificates.