Prev  Up  Next
Chapter 14. Create Initial Privileges (STEP 7)  Home  Chapter 16. Secure Your Tables (STEP 9)

The demo chooses to use only Veil2's role tables for its roles implementation. This makes things very simple, but may be unhelpful as an example. The author apologizes but there are some things you will have to do for yourselves. Look for STEP 8 in the file demo/veil2_demo--0.9.1 (beta).sql.

If your existing system has roles of some sort that you wish to keep using, you are going to have to find a way to integrate them with the veil2.roles table.

There are essentially three options:

This is likely to be a reasonably complex process. You are going to need:

  • an id mapping mechanism;

    Your existing role keys are not going to work with Veil2, so we will need a way to map your role keys with Veil2's role_ids. Note that you need to keep the range of role_ids as small as possible in order to keep their bitmap representations small.

    You will need to create a table that maps between veil2.roles and your database's roles table(s). Use foreign key relationships and triggers to ensure that your mapping table is kept in step with your existing table and the veil2.roles table.

    For some examples of how the triggers can be constructed take a look at the demo. In particular the way that the demo's parties table is linked to veil2.accessors.

Whether this will work, will depend on the semantics of your existing role implementation. If they are similar to Veil2's role semantics, this may work. You will have to do some careful thinking about this.

If your application has user-level roles (roles that are assigned to users), you may be able to re-use them. You will probably not have function-level roles however, and you will need to at least create a minimal set of these.

The minimal set of user-level roles should be enough to give you 2 or more pieces of functionality that you can then use to test your access control mechanisms. To these roles, you will assign privileges by creating records in veil2.role_privileges.

You will then need to create role to role mappings, making your function-level roles available to your user-level roles. You will do this by creating records in veil2.role_roles.

As with privileges, you should keep the range of role_ids as small as possible, allocating them contiguously and re-use ids for records that get deleted.

Note that if you have decided to use role to role mappings in anything other than the global context you will need to define your mappings in each of those contexts. Your role names may also need to be customized for those contexts. This is shown in the demo; look for the text STEP 8.

Any time that role to role or role to privilege mappings are updated, all materialized views and caches must be updated.

Since these mappings are managed exclusively from Veil2 tables, all the necessary triggers to refresh our materialized views are already in place.

Prev  Up  Next
Chapter 14. Create Initial Privileges (STEP 7)  Home  Chapter 16. Secure Your Tables (STEP 9)