Goal
As data becomes the lifeblood of the modern enterprise, securing its usage is more essential than ever. While Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) form the foundation of data security, Denodo also supports the definition of Time-Based Access Control (TBAC) policies.
TBAC allows administrators to define specific time windows for data access, automatically granting or revoking privileges based on pre-defined schedules. By ensuring that sensitive data is only accessible when it is truly needed, TBAC significantly reduces the attack surface and provides more robust security oversight.
You can easily implement TBAC policies in the Denodo Platform through Dynamic Security Policies. This article provides a comprehensive, step-by-step guide to configuring this kind of policy to enhance your data governance strategy.
Configuration Steps
Prerequisites
Before implementing Time-Based Access Control (TBAC), ensure you are familiar with the core concepts of Denodo Dynamic Security and Global Security Policies. Dynamic Security policies were introduced in Denodo 9.3, so this approach requires Denodo 9.3 or a more recent version.
In this example, we are enabling TBAC through the use of an external table that contains the approved data access time windows for each user and Denodo view. In the example table below we have fields for the username, target database, target view, the access start dates, and access expiration dates. This is a flexible approach that can be extended to other scenarios, where the time windows agreement is kept in an external application, a simple file, or an external API.
Defining the Policy
The enforcement of the access time window will be controlled with a Denodo Global Security Policy. To do so, create a new Global Security Policy, configure the corresponding “Audience” and “Elements” sections, and for the “Restriction" section select "Apply a custom view policy". Then click on “Add custom policy” to configure the details of the TBAC.
As mentioned above, we will use the "dynamic restriction policy”, packaged by default in all Denodo installations starting in Denodo 9.3.
In addition you will need to provide the following configuration:
- The name of the database where your security lookup table is located.
- The view name of your security lookup table.
- Policy rule definition (JSON): The logic that defines how access is granted. This is where the logic of the lookup in the external security table is defined. More details below.
- Default behavior when rule is missing: In the example above it is set to “DENY” This ensures that if no matching rule is found (i.e., the user is outside their access window or no access is granted), Denodo will throw a privileges error. Other options are listed in the documentation for Denodo Dynamic Security.
Rule Definition Example
Below is the JSON configuration for the Policy rules parameter:
{ "searchExpression": "lower(user_name)=lower(@USER_NAME) AND lower(database_name)=lower(@ELEMENT_DATABASE) AND lower(view_name)=lower(@ELEMENT_NAME) AND current_date() >= access_start_date AND access_expire_date >= current_date()", "rules": [ { "antecedentCondition": "1=1", "mappings": [ { "key": "user_name", "value": "dummy" } ], "consequentCondition": "1=1" } ] } |
The logic in the example dictates that a user can only access the data if the current date falls within their authorized window:
Access Condition: Start Date <= Current Date <= Expiration Date |
If the user does not meet this condition, including has “NULL” value for the date parameters, the search expression returns no rows, the policy fails to trigger, and the Default Restriction kicks in, displaying an error message.
With all the configurations in place, save the policy for it to take effect.
Example
Using John Doe as an example: his record in the security lookup table shows an active date range for the "customer" table.
Assuming that the current date is “2026/05/10” when John executes this query, the policy validates his window for this particular table and grants access to the data.
On the other hand, if John Doe’s access has expired like for the account table. His record will no longer satisfy the current_date() check in the policy.
When he attempts to see the view, Denodo will return a privileges error, as shown below:
The Power of Dynamic Updates
A key advantage of this model is that it is entirely dynamic. Changes made to the security lookup table are applied at runtime. If an administrator extends John Doe’s access window in the underlying table, John will immediately be able to view the data upon refreshing his query—no redeployment or policy modification required.
Restrictions
The "Null" Date Trap
As mentioned in the previous sections, if the date variables are null, the record will not return as a result. If the administrator wants to grant permanent access, a far-future date (e.g., 9999-12-31) would be more appropriate.
Administrative Overrides
By design, users with Admin privileges bypass Global Security Policies.
Time Zone Discrepancy
Since the logic uses current_date() or now(), the policy will use the time zone of the Denodo Server, not the user’s local machine. If your team is global, a user in London might lose access "early" if the server is in New York. In this case store dates in the designated timezone or use of the AT TIME ZONE function would be helpful.
References
The information provided in the Denodo Knowledge Base is intended to assist our users in advanced uses of Denodo. Please note that the results from the application of processes and configurations detailed in these documents may vary depending on your specific environment. Use them at your own discretion.
For an official guide of supported features, please refer to the User Manuals. For questions on critical systems or complex environments we recommend you to contact your Denodo Customer Success Manager.
Recommended resources Recommendations generated by AI
Questions
