We include hereinafter a description of the security support in the Denodo Platform. The following diagram highlights the Denodo Platform Security architecture.
Figure 1: Denodo Platform Security Architecture
The Denodo Platform Security Architecture has the following features:
Denodo’s fine-grained, role-based access control includes row- and column-level permissions, full integration with LDAP/Active Directory for sourcing user identities and group-based authorizations to virtual views.
Denodo Roles, defined in a Denodo Virtual Database, aggregate permissions on individual users (defined externally in LDAP/AD or natively as Denodo virtual database users) for accessing virtual database schemas (data sources, views, web services, stored procedures), etc.
Denodo Virtual DataPort distinguishes two types of users:
A ‘Normal user’ can have ‘Roles’, sets of access rights over virtual databases and their virtual views and stored procedures. Roles allow administrators to manage user privileges easily because by changing the privileges assigned to a role, they change the privileges of all the users assigned that role.
Virtual DataPort access rights are applied to a specific user or a role, to delimit the tasks they can perform over databases, views and stored procedures. Access rights can be applied globally to a database or specifically to a view/stored procedure in a specific database. Virtual DataPort supports the following types of global database access rights: Read, Create, Write, and Connection Access. Virtual DataPort also supports individual privileges to specific views and stored procedures. The privileges that can be applied to a specific view and/or stored procedure of a database are: Read, Write, Insert, Update, and Delete. Within Read privileges on a view, a user (or a role granting same), can query this view to obtain all its data. However, if certain users or roles should have access to only some of the columns of a specific view, you can use ‘Column privileges’ and ‘Row privileges’ to further constrain “Read” access.
Roles can be “hierarchical”. Once a baseline role is established, another role can be created which “inherits” and refines it. These “role hierarchies” can be built to any depth within Denodo.
Figure 2: Creating role hierarchies
Denodo can delegate the authentication to the designated LDAP/Active Directory system. Roles can be imported from either third-party source at any time, and then configured to constrain access to Denodo’s virtual databases and views.
A database with LDAP authentication delegates the authentication of users to an LDAP server. The benefit over the ‘Normal’ authentication is that you can rely on an LDAP server such as the Microsoft Windows Active Directory, to authenticate users without having to create them in Virtual DataPort.
The Server also obtains the names of the roles that the users belong to, from the LDAP server and uses them to check which actions the users can do.
When a user tries to connect to a LDAP database, the Server checks first if the user is a Virtual DataPort “administrator”. If not, it connects to an LDAP server to check the credentials and obtain the roles of the user.
Figure 3: Configuring virtual database with LDAP authentication
Denodo can enforce strict, fine-grained user and role-based permissions for each and every element defined within it. Denodo’s authorization policies can implement row and column security. These policies are specified by view, by row (specified with a selection condition), by column or by row-column combination (i.e. rows restricted but only for restricted columns), and are evaluated prior to each query execution to determine if the customer is allowed to see particular results or not.
For example, Denodo’s row-level security would allow hiding the salary of people with position=’manager’ when querying a ‘salary’ view from users with an ‘employee’ role (thus not entitled to access salary information).
Denodo supports delegating authentication / authorization to LDAP, Active Directory. It also supports pass-through of user credentials to data sources for principal propagation, therefore allowing to leverage existing authentication infrastructures. Also it supports sources with OAuth authorization. Denodo also includes support for SSO of client applications using Kerberos.
When accessing cached data, the same security restrictions of the user/role on a given database, view, columns and/or rows are taken into account.
Custom policies allow developers to provide their own access control policies. Similar concepts already exist in some systems such as Oracle (Virtual Private Database Policies). Developers can code their own custom access control policies and the administrator can assign them to one (or several) users/roles in a view in Denodo. When a given user/role executes a query on that view, Denodo invokes the code of the policy. The policy may return:
The implementation of the policy has available the context of the query (user, projected fields, VQL statement, ...). Custom policies can be used to integrate an external Policy Server (e.g. Axiomatics) to provide dynamic authorization based on policies defined in such server.
Figure 4: Policy-base security
Examples of possible uses: set limits to the number of queries executed by a certain user/role; determine if a query can be executed depending on the time of the day or leveraging the access policies in an external policy server.
Figure 5: Dynamic Authorization based on policies
Denodo’s hybrid approach to data integration, allows different data access & delivery modes, all of which may involve securely accessing sensitive data: real-time from the data sources; from the Denodo cache; or from a staging area (i.e. ETL-like process where data is moved from its original data source to an external repository).
In order to cover all possible scenarios, Denodo supports the application of strategies on a per view basis to guarantee secured access to sensitive data through encryption/decryption at different levels.
Data at rest (secured caching of sensitive data or storage in staging area)
Data in motion (securely accessing and delivering data):