Exotic and Esoteric uses of Veil

Actually this is neither exotic nor particularly esoteric. The title is simply wishful thinking on the author's part.

Multi-Layered Connections

So far we have considered access controls based only on the user. If we wish to be more paranoid, and perhaps we should, we may also consider limiting the access rights of each application.

This might mean that reporting applications would have no ability to update data, that financial applications would have no access to personnel data, and that personnel apps would have no access to business data.

This can be done in addition to the user-level checks, so that even if I have DBA privilege, I can not subvert the personnel reporting tools to modify financial data.

All access functions would check the service's privileges in addition to the user's before allowing any operation.

This could be implemented with a connect_service() function that would be called only once per session and that must be called prior to connecting any users. Alternatively, the connected service could be inferred from the account to which the service is connected.

Column-Level Access Controls

Although veil is primarily intended for row-based access controls, column-based is also possible. If this is required it may be better to use a highly normalised data model where columns are converted instead into attributes, much like the person_details and project_details tables from the demo application (The Veil Demo Application).

If this is not possible then defining access_views that only show certain columns can be done something like this:

create view wibble(key, col1, col2, col3) as
select key, 
       case when have_col_priv(100001) then col1 else null end,
       case when have_col_priv(100002) then col2 else null end,
       case when have_col_priv(100003) then col3 else null end
where  have_row_priv(1000);

The instead-of triggers for this are left as an exercise.

Next: Installation and Configuration