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:

• Prepare to test an RBAC configuration.

• Test an RBAC configuration using sample submission data.

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	Email
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	Email	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.