Application authorization
In order to control user’s access to the right data, you can apply role-based access control (RBAC) or another authorization permission systems in your application. We will specifically focus on multi-employer RBAC authorization. Multi-employer RBAC involves 4 core elements:- Users: A user is an individual who is trying to access their employment data which they granted you access to via Finch Connect. A
user
is assignedroles
, which in turn grant them thepermissions
they need to access resources. In a multi-employer RBAC, users typically belong to a particularemployer
and their permissions and roles are scoped to that employer. A user in one employer should not, by default, have any permissions or roles in another employer unless explicitly granted. - Roles - A role is a collection of permissions that define the actions a user can perform in your application. A role is assigned to a user, and a user can have multiple roles. In a multi-employer environment, roles are typically scoped to a particular employer so that an “Admin” role in Employer A might have different permissions than an “Admin” role in Employer B.
- Permissions - A permission is a right to perform a specific action or access a specific resource in your application. Permissions are assigned to roles. In a multi-employer context, permissions should be defined in a way that they are also scoped to specific employers. This ensures that granting a permission in one employer doesn’t inadvertently grant access to resources in another employer.
- Employers: An employer is the foundational element of multi-employer scenarios. Each employer represents an isolated unit or environment in your application, like a separate company or organization. Your application must be able to separate and manage data, configurations, and roles for each employer independently, ensuring there’s no overlap or unintended sharing.
Building upon the database tablesCross-Employer Authorization
There may be scenarios where a user needs access across multiple employers (maybe they manage multiple employers for a PEO, or Professional Employer Organization. In such cases, your RBAC authorization system must support cross-employer roles and permissions without compromising the security or isolation of individual employers.
customers
& finch_connections
defined in the Manage Connections guide, in order to implement multi-employer RBAC, we need a few additional tables.
customers
: Represents the “entities” who use your system.finch_connections
: Represents the different connections (i.e. employers) a customer might have in your system.users
: Represents individual users within a particular employer. Each user is associated with a specific connection, which defines the context of their roles and permissions.roles
: Represents different roles that can be assigned to users within an employer. Each role is associated with a particular connection, signifying the context in which the role exists.permissions
: Represents the different actions or operations that can be performed within your system. Permissions are not directly linked to a connection as permissions are typically more generic and can be used across multiple connections.role_permissions
: A junction (or associative) table that establishes a many-to-many relationship between roles and permissions. Allows you to assign multiple permissions to a single role and vice versa.user_roles
: Another junction table, but this one links users and roles. It determines which roles are assigned to a user in the context of a connection. Each combination signifies the roles a user has within a particular connection, which in turn dictates what actions they can perform with their employment data.
Admin
role since it is the employer’s HR & Payroll admin who should only have the permissions to go through Finch Connect and establish a connection with their employment system. Since a regular employee does not have the permissions to see the whole company-wide details or payroll, they should not be shown the option to connect via Finch.
Reminder
SQL queries via JOIN statements are only one way of implementing multi-employer role-based access control. There are many ways to implement access control that allow more fine-grained authorization or robust permissioning. Choose the best option for your application’s needs.Checkpoint + Next Step
After completing this step, you should be familiar with the database techniques necessary to effectively track the relationship between user accounts and access tokens and implement data access controls based on user roles or permissions. You are now ready to Manage Connections.