Denodo Platform 9 Certified Developer Professional study materials
Denodo Platform 9 Certified Developer Professional study resources

Denodo Platform 9 Certified Developer Professional: Data Security: Authentication, Authorization, and Data Masking

Denodo Platform 9 Certified Developer Professional · Work through your exam, one topic at a time.

All guide sections

Data Security: Authentication, Authorization, and Data Masking

What this domain tests

Security questions ask who gets in, what they may run, which rows they see and which values are hidden. Expect authentication modes, privilege grants at database/folder/view level, row filters, and masking designs.

Authentication

VDP can authenticate against its own user store or delegate to LDAP/Active Directory, importing users and roles. Kerberos supports single sign-on, and web services can use HTTP Basic, OAuth or SAML depending on the service. Separately, pass-through authentication forwards the caller's identity to the data source so source-side security still applies.

Authorization

Privileges are granted to users and roles at database, folder and view level: connect, metadata, execute and write. Grant the narrowest object that satisfies the requirement. Row filters attach a boolean expression to a view for a user or role; the expression is injected at query time and can call context functions such as user_name() to compare against a mapping view. Because the filter lives on the view, it applies to every client - JDBC, REST, GraphQL - without client cooperation.

Masking

Masking is normally implemented with a masking view that projects the safe columns and replaces sensitive ones (partial values, hashing, nulling), with execute granted on the masking view and revoked on the base view. Denodo 9 also supports policy-driven masking tied to classification, but the principle is the same: the identity of the caller determines the transformation at query time.

Worked example

Analysts must see orders only for their own region, with the tax identifier masked. Reasoning: create a row filter on the orders view for role analyst using user_name() joined to a mapping view of user-to-region; create a masking view that projects all columns except the tax identifier, which is replaced with a masked expression; grant execute to analyst on the masking view and revoke it on the base view. Verify by connecting as an analyst over REST, not only in the admin tool.

Traps that cost marks

  • Granting execute on the base view while believing the masking view protects it.
  • Caching a masked or row-filtered view and serving cached rows across identities.
  • Row filters on one view while joins expose the unfiltered base view.
  • Leaving default public grants in place after tightening a role.