Testing and Troubleshooting a Client's RBAC Infrastructure
Overview
When building out a client's RBAC infrastructure, you'll need to rigorously test the configuration to ensure everything works as requested. To do that, there are a few troubleshooting techniques you can use.
NOTE This article relies on the RBAC infrastructure laid out in our Building a Client's RBAC Requirements article. Refer back to that sample infrastructure if you need clarity on the role hierarchy or groups at any point in this article.
What You'll Learn
In this article, you'll learn how to:
Preparing to Test
Before you start testing your RBAC, you'll need to do some preparation. The goal is to only allow end-users to see certain submission data based on their role and groups. So, start by listing all the end-users you'll need to test. Then, map out which submissions you want each account to have access to.
Creating Test Accounts
It's a best practice to use two accounts for every role and every group. For this example, you need to test City Admins, Agency Admins, Program Managers, and Clients. You also need to test the separate groups for Agency 1 and Agency 2. Here's what a list of examples users looks like:
-
City Admin A
-
City Admin B
-
Agency Admin 1A
-
Agency Admin 1B
-
Agency Admin 2A
-
Agency Admin 2B
-
Program Manager 1A
-
Program Manager 1B
-
Program Manager 2A
-
Program Manager 2B
-
Client 1A
-
Client 1B
-
Client 2A
-
Client 2B
Now that you have this list, you'll need to create the unique logins for each. Instead of using a different email for each account, you can use variations of your own. When you type your own email address, add a + followed by a unique string between the user name and the @ sign. Keeping these strings reflective of the account you're assigning them to is useful. For example, the City Admin A email address could be your_email+caa@unqork.com. Here's a list of each account along with sample emails:
Name | |
---|---|
City Admin A |
your_email+caa@unqork.com |
City Admin B |
your_email+cab@unqork.com |
Agency Admin 1A |
your_email+aa1a@unqork.com |
Agency Admin 1B |
your_email+aa1b@unqork.com |
Agency Admin 2A |
your_email+aa2a@unqork.com |
Agency Admin 2B |
your_email+aa2b@unqork.com |
Program Manager 1A |
your_email+pm1a@unqork.com |
Program Manager 1B |
your_email+pm1b@unqork.com |
Program Manager 2A |
your_email+pm1b@unqork.com |
Program Manager 2B |
your_email+pm2b@unqork.com |
Client 1A |
your_email+c1a@unqork.com |
Client 1B |
your_email+c1b@unqork.com |
Client 2A |
your_email+c2a@unqork.com |
Client 2B |
your_email+c2b@unqork.com |
Next, you'll record the role and groups for each account:
Name | Role | Group(s) | |
---|---|---|---|
City Admin A |
your_email+caa@unqork.com |
CityAdmin |
dept-labor-admin agency-1 agency-2 program-1 program-2 |
City Admin B |
your_email+cab@unqork.com |
CityAdmin |
dept-labor-admin agency-1 agency-2 program-1 program-2 |
Agency Admin 1A |
your_email+aa1a@unqork.com |
AgencyAdmin |
agency-1 program-1 |
Agency Admin 1B |
your_email+aa1b@unqork.com |
AgencyAdmin |
agency-1 program-1 |
Agency Admin 2A |
your_email+aa2a@unqork.com |
AgencyAdmin |
agency-2 program-2 |
Agency Admin 2B |
your_email+aa2b@unqork.com |
AgencyAdmin |
agency-2 program-2 |
Program Manager 1A |
your_email+pm1a@unqork.com |
ProgramManager |
program-1 |
Program Manager 1B |
your_email+pm1b@unqork.com |
ProgramManager |
program-1 |
Program Manager 2A |
your_email+pm1b@unqork.com |
ProgramManager |
program-2 |
Program Manager 2B |
your_email+pm2b@unqork.com |
ProgramManager |
program-2 |
Client 1A |
your_email+c1a@unqork.com |
Client |
program-1 |
Client 1B |
your_email+c1b@unqork.com |
Client |
program-1 |
Client 2A |
your_email+c2a@unqork.com |
Client |
program-2 |
Client 2B |
your_email+c2b@unqork.com |
Client |
program-2 |
Once you have this sheet created, you can upload a CSV version on the User Creation page. This lets you create all of your test accounts at once.
NOTE You can also include a password column where you can assign a temporary password to each account.
Mapping Out Submission Access
With testing accounts created, you'll lay out which data you want each account to access. Like with the accounts above, it is useful to do this visually. We'll use tables with columns showing whether an account has access to another end-user's submission data. If you see a colored cell, that means the account in the header of that column has access to the end-user's data shown at the left of the row.
NOTE You know each account should have access to their own data. Because this is typical behavior, you won't see it shown in the following visuals.
Let's start with the City Admin roles. You know these accounts should have access to everyone's submissions:
User Name | City Admin A | City Admin B |
---|---|---|
City Admin A |
|
|
City Admin B |
|
|
Agency Admin 1A |
|
|
Agency Admin 1B |
|
|
Agency Admin 2A |
|
|
Agency Admin 2B |
|
|
Program Manager 1A |
|
|
Program Manager 1B |
|
|
Program Manager 2A |
|
|
Program Manager 2B |
|
|
Client 1A |
|
|
Client 1B |
|
|
Client 2A |
|
|
Client 2B |
The Agency Admins should see submissions from the City Admins and anyone at their own agency. This is where you start to see differences within a role depending on the group assignment:
User Name | Agency Admin 1A | Agency Admin 1B | Agency Admin 2A | Agency Admin 2B |
---|---|---|---|---|
City Admin A |
|
|
|
|
City Admin B |
|
|
|
|
Agency Admin 1A |
|
|
|
|
Agency Admin 1B |
|
|
|
|
Agency Admin 2A |
|
|
|
|
Agency Admin 2B |
|
|
|
|
Program Manager 1A |
|
|
|
|
Program Manager 1B |
|
|
|
|
Program Manager 2A |
|
|
|
|
Program Manager 2B |
|
|
|
|
Client 1A |
|
|
|
|
Client 1B |
|
|
|
|
Client 2A |
|
|
|
|
Client 2B |
|
|
|
|
Program Managers should see submissions from all clients in their program, but they should not see submissions from other Program Managers:
User Name | Program Manager 1A | Program Manager 1B | Program Manager 2A | Program Manager 2B |
---|---|---|---|---|
City Admin A |
|
|
|
|
City Admin B |
|
|
|
|
Agency Admin 1A |
|
|
|
|
Agency Admin 1B |
|
|
|
|
Agency Admin 2A |
|
|
|
|
Agency Admin 2B |
|
|
|
|
Program Manager 1A |
|
|
|
|
Program Manager 1B |
|
|
|
|
Program Manager 2A |
|
|
|
|
Program Manager 2B |
|
|
|
|
Client 1A |
|
|
|
|
Client 1B |
|
|
|
|
Client 2A |
|
|
|
|
Client 2B |
|
|
|
|
Clients should only see their own submissions:
User Name | Client 1A | Client 1B | Client 2A | Client 2B |
---|---|---|---|---|
City Admin A |
|
|
|
|
City Admin B |
|
|
|
|
Agency Admin 1A |
|
|
|
|
Agency Admin 1B |
|
|
|
|
Agency Admin 2A |
|
|
|
|
Agency Admin 2B |
|
|
|
|
Program Manager 1A |
|
|
|
|
Program Manager 1B |
|
|
|
|
Program Manager 2A |
|
|
|
|
Program Manager 2B |
|
|
|
|
Client 1A |
|
|
|
|
Client 1B |
|
|
|
|
Client 2A |
|
|
|
|
Client 2B |
|
|
|
|
You can use these charts as worksheets to record your tests and confirm that your RBAC is set up correctly.
Testing with Sample Submissions
With the reference sheets from above, you can now start testing your RBAC. To do that, you'll create simple submissions using each account. Then, you'll view a dashboard of those submissions using each account too. You'll work your way through the submission data sheet from left to right. So, you'll view the dashboard as the City Admin A. Once you confirm that you see all expected submissions as that user, you'll move onto City Admin B. You'll do this for each column in your sheet until you test each account's access.
TIP To easily log into multiple accounts at a time, use a form of private browsing. For example, if you're using Chrome, open a new Incognito window to perform your tests.
Creating Submissions
To create test submissions, you can use something as simple as a form with a Text Field that collects an end-user's user name. Here's how that module looks in the Module Builder:
And here's what you see in Express View:
You'll log in to this module using each of your test accounts and submit the form. This gives you a sample submission created under each role and group. These sample submissions are key to the next step in testing your RBAC.
You can view this sample module here: https://training.unqork.io/#/form/611bc8920b86ad19bde792fe/edit.
NOTE If your roles are set to have No Access from an environment level, remember to grant them Write access at the module level in order to test your RBAC here.
Viewing Submissions
To view your test submissions, you'll display them in a dashboard. Here's how that module looks in the Module Builder:
And here's what you see in Express View when logged in under the Administrator role:
You can view this sample module here: https://training.unqork.io/#/form/611bc8b201418e18dc79607e/edit.
NOTE If your roles are set to have No Access from an environment level, remember to grant them access at the module level in order to view your test submissions. Read-Only permission will suffice for your testing purposes.
Viewing this dashboard as the Administrator, you'll see all of your submissions because this role has access to everyone's submission data. This is a good way to verify that your submissions were created correctly before testing out the rest of your accounts. From there, you can work your way down your list of accounts, starting with City Admin A.
Logging in as the City Admin A, you'll see all of your test submissions in your dashboard:
It's a good idea to mark each submission off on your tracking sheet so you know what you need to fix, if anything. And if all looks correct when logged in as City Admin A, you also know it will look correct as City Admin B since these two accounts share the same role and groups. The purpose of City Admin B is to provide a sample submission in the same role and group as City Admin A to accurately test your RBAC. So, you can move onto the next account.
Next, log in as Agency Admin 1A. Based on the tracking sheet, this account sees submissions from all users in Agency 1, and they also see submissions from the City Admins:
Just as with the two City Admin accounts, if Agency Admin 1A's permissions appear correct, you can assume that Agency Admin 1B's permissions are also correct because they have the same RBAC assignments.
For Agency Admin 2A, you can expect to see the same number of submissions as you did for Agency Admin 1A. The only difference here is they'll see the submissions from Agency 2 instead of Agency 1. But let's say you see something like this:
You'll notice submissions from the City Admins are missing. If this happens for any account, you'll need to double-check the configuration for your groups as well as your role hierarchy. In this case, you can return to Express Group Administration and see the agency-2 group type is set to Data Access to Own Role and Role Descendants Only:
Because the City Admin role is above the Agency Admin role in your hierarchy, this setting doesn't allow the Agency Admin to see data from a City Admin. Switching the group type to Data Access to All Roles in Hierarchy solves this issue:
And refreshing your dashboard while logged into this account now shows the following submissions:
Next, testing the Program Manager 1A account, you'll see their own submission as well as submissions from Client 1A and Client 1B:
Program Manager 1B has different permissions than Program Manager 1A. Remember that Program Managers don't see each other's submissions. So, you'll log in as Program Manager 1B next and verify they see their own submission but not Program Manager 1A's in the dashboard:
From there, you can continue with Program Managers in Agency 2. The same permissions you checked for the previous Program Managers apply here, except every submission is from Agency 2. Here's what Program Manager 2A sees:
And here's what Program Manager 2B sees:
Now all that's left to test are the Client accounts. Clients should only have access to their own submissions, so that's all they should see when viewing the dashboard. For example, here's what Client 1A sees:
The dashboard view is the same for all Client accounts, and only one submission shows. The only difference is the submission that displays belongs to the account you used to log in.
Testing your RBAC is critical and should be done before configuration starts on your application. Creating a simple application like the form and dashboard from this example is the best way to check your RBAC configuration. The bulk of the work in testing your RBAC configuration is creating a clear plan of your expectations and then creating sample data to test it all out. This lets you build your application knowing that your roles and groups are configured properly.