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.
In this option, we replace your roles implementation with that
from Veil2 but make it look like your
existing implementation is still in place.
The key to this is to use views and instead-of triggers to
make the Veil2 table function in the same
way as your existing table.
As with the previous option, this will require some serious thinking, but it will probably give you a simpler system than the previous option. Roles and privileges are complex enough without adding an extra level of redirection.
This is conceptually the simplest approach but the amount of work will very much depend on your existing system and its needs.
The demo chooses to use Veil2's
implementation of roles, rather than integrating any existing
role implementation. Since the demo was built with
Veil2 in mind this makes a lot of sense as
it keeps the implementation much cleaner and simpler.
If you are building a new system from scratch, this should be your preferred approach.
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.