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.