It is likely that your application is going to have tables that
represent users. The next stage of your implementation is going
to be to link your users with Veil2's
accessors.
Look for STEP 4 in the file
veil2_demo--<version>.sql.
You will need to create links between each of your user tables
and the veil2.accessors
table.
You will create foreign-key constraints back to those tables,
and create triggers to keep the mapping and
accessors tables in step with changes in your
users tables.
You will create a mapping table, ideally in the
veil2 schema, that will consist of foreign key
references to both the veil2.accessors table
and whatever tables from your database that need you need to link
to. You will also create indexes for performance, and
foreign-key references back to your users tables.
Note that as a simplification, the demo chooses to use the
accessor_id from the
accessors table as the primary key for its
parties table.
Create copies of the existing user records in
veil2.accessors. Note that you will need to
create records in both the
veil2.accessors and the new mapping table for
each users record. See the demo.
What we need to do is populate the
veil2.authentication_details
table from the authentication details (passwords) in your source
database. Depending on how secure your existing system is, this
may prove to be difficult. For instance if you use a simple
salted hash to store your passwords, you will be unable to
generate a bcrypt password from it. In this case you have
2 basic choices:
implement your current password management scheme in
Veil2;
In this case you will be able to simply copy the current hashed passwords.
implement a password migration scheme.
You will create bcrypt tokens from the users' passwords, as they enter them into your system.
When new users are created, updated or deleted in your users
table, we need the veil2.accessors records to
reflect this. Triggers on your users tables must be created to
achieve this.
Ideally, on an ongoing basis, all authentication details will be
kept solely in veil2.authentication_details
and use of the original users tables for this will be
deprecated. Until this can be completed though, you may still
be allowing passwords etc to be created in your original users
tables.
To ensure that password changes are propagated to
Veil2, triggers should be placed on the
source tables which will cause the appropriate modifications to
be made to veil2.authentication_details.
Again, examples can be found in the demo code.