User Management and Access Control - Beta

[seanmalbert]

Current Implementation

To date, user management and access control is largely a manual process and managed by the internal team. The definition/configuration of a user is also lacking, as they currently aren't associated with a jurisdiction. I was going to split this into two separate discussions, one for user management and one for access control, but with its current state and where we want to go in the immediate future, it was hard to decouple the two.

There are two types of partner portal user:

• admin
• user

Currently, there are only two types of user roles (UserRole enum) admin and user. If the user's role includes UserRole.admin then they have access to all listings, if they don't, then they can only see the listings that were assigned to them (see leasingAgentInListings on the user), which is also a manual process.

Access control and authorization are handled via a very basic implementation of Casbin, using an RBAC model. Within the checking of can the leasingAgentIntListings are mapped to permissions for the user with full CRUD actions.

Proposed Next Steps

Backend

Updates to User

The partner's portal needs to support three types of users:

• super admin (Bloom internal)
• jurisdiction admin
• jurisdiction user

Super Admin

The super admin user can be accomplished relatively easily by adding a boolean onto the user, like "bloom". If that's set to true, then the user has access to everything. Only our internal team users would have this set. We could additionally require the user's email to match a regex. How this plays out though, is that during the check if a user "can" do something, if a user is "bloom", then we can return true.

General User Model Updates

Aside from adding the super admin "bloom" flag, we want to relate users to jurisdictions. Users can belong to more than one jurisdiction. We can also remove the isAdmin flag, since we're going to create a role for that which will be related to the user via a different entity (see below).

Access Control

We can continue to use Casbin for its management and enforcement capabilities (though now would be the time to change if we're going to). We do not yet need to add a role manager and policy storage outside of what we're doing now, but when we have a UI to configure roles, we will want to.

Jurisdiction checking

Once users are related to jurisdictions, the can method in authz.service can be updated to include something like '${listing.county_id}' in (r.obj.jurisdiciton_id) (note that county_id on the listing should be updated to jurisdiction_id).

This will enforce that the user and the listing they're trying to access belong to the same jurisdiction.

User/Listing bindings

As noted in the current implementation section, users are "bound" to listings via the leasingAgentInListings key on a user. In the interest of getting an initial basic UI working, this is probably fine for now, but we will need a more robust way to manage direct assignments of a record to another record.

As a brief overview of the model, if we had a table with the following (approximate) fields:

• id
• jurisdiction_id
• user_id
• node_type (listing, application, role?, etc)
• node_id (the id of the record (listing, application, etc))

If we needed a hierarchy of users, with a concept of groups of users, then we could replace user_id with owner_id and owner_type fields.

UI

User Management

We need a section in partner's to manage user's, which for now would only be accessible by super admins, which is mocked up here.

We will want the user/people list and the ability to add a user. Since we won't yet have a jurisdictional "context" switcher, the user form should have a way for a super admin user to select which jurisdictions a user is in.

User/Listing binding

In partners, from a listing detail page, a super admin or admin should be able to see the users (leasing agents) assigned to a listing. From there, they should be able to remove or add users that are already in the system to a listing. Upon saving, the user would be updated with the listing ID added to user.leasingAgentInListings (assuming we don't want to go a more robust route now).

[seanmalbert]

@willrlin ,
Can your team take a look at this. It better explains what the current user/access control setup and briefly outlines a way to address our more immediate needs. What considerations should we have for Detroit?

[willrlin]

I think Detroit's HRD might want the ability to manage users and to have this UI (I guess they could just be the super-admin account for our deployment). Can a user be both a public user and a partner portal user?

[willrlin]

Could you also ensure that the Figma mocks are shared with at least @tomgebauer, @kar-r-green, and myself? So we know what the plan is.

[slowbot]

Can you share emails for the folks you would like added to the file? You can always email them to me. I have Tom added already. @willrlin

[willrlin]

Sent, thanks!

[seanmalbert]

I think Detroit's HRD might want the ability to manage users and to have this UI (I guess they could just be the super-admin account for our deployment).

An admin would be able to manage user's to the extent that those user's would be assigned to listings. Though, we could amend this so that an admin could create another admin under the jurisdiction(s) they themselves were given access. I think I would prefer that over giving users super admin access.

Earlier mocks that @slowbot created, had a role dropdown, which we could incorporate and have the two "roles" we have now selectable. If "admin" is selected, the user would be an admin like themselves and if "user" is selected, then they would only have access to the listings that were assigned to them.

Can a user be both a public user and a partner portal user?

I suppose technically a user could be a public and a partner portal user, but I don't think we would ever see that in practice, aside from a leasing agent or developer testing out the public site with their same email address they use for the partner portal.

[willrlin]

Just wanted to write down here so I didn't forget - @seanmalbert and I spoke yesterday about this and realized that there needs to be a distinction between public users and partner portal users such that if Detroit wanted to enable partner portal users to create new listings, we wouldn't also accidentally enable public users to create listings.

[seanmalbert]

Generated #1616 from this. Thanks, @willrlin!

[pbn4]

Here is my proposal for how we could solve this with casbin. Let's start from some use cases / requirements:

1. Superadmin can do everything
2. Jurisdiction admin can do everything within a jurisdiction
3. Leasing agent can edit applications for a given listing he/she is assigned to (possible multiple assignments)
4. User can read his own applications
5. Audit (made up use case) requires read to all applications in given jurisdiction (possible multiple jurisdictions)

Model will be similar to what AWS IAM policies look like e.g. every identity in the system has a list of policies assigned to it that are evaluated in order to determine whether a user is ALLOWED or DENIED to perform an action on a resource. Everything is denied by default. If a resource is on a list of policies it means that user is allowed to perform some action on it (e.g. there are no entries that deny anything, it's an allow list).

Policies are kept in a DB table (e.g. auth_policies) and have a composite primary key (id, user_id). This new table contains
also a resource string column and an action string column. Each time an authorization needs to be checked all policies for a given user are fetched from the DB (some redis based caching could be useful here, because those will not change too often) and evaluated, if there is any policy matching the resource identifier regexp (casbin supports wildcards) it's action regexp is compared to the action user wants to perform.

Examples policies:

1. Superadmin:
   admin_user_id_1, *, * - user 1 can do everything
   admin_user_id_2, *, * - user 2 can do everything
2. Jurisdiction admin:
   jurisdiction_admin_user_id_1, jurisdictions/jurisdiction_1_id/*, * - user 1 can do everything in jurisdiction 1
   jurisdiction_admin_user_id_2, jurisdictions/jurisdiction_1_id/*, *- user 2 can do verything in jurisidction 2
3. Leasing agent assigned to multiple listings
   leasing_agent_user_id_1, jurisdiction_id/1/listings/1/applications/*, (read|edit|create|delete) - user 1 can read/edit/create/delete applications in listing 1
   leasing_agent_user_id_1, jurisdiction_id/1/listings/2/applications/*, (read|edit|create|delete) - user 1 can read/edit/create/delete in listing 2
4. User can read his own applications
   user_id, jurisdiction_id/1/listings/1/applications/1, read
5. Audit
   audit_user_id_1, jurisdiction_id/1/listings/*/applications/*, read - user 1 can read every application in jurisdiction 1
   audit_user_id_1, jurisdiction_id/2/listings/*/applications/*, read- user 1 can ready every application in jurisdiction 2

Important note is that this completely removes a concept of a role. Now the API is very simple, it's just a REST endpoint with standard GET/PUT/DELETE actions over auth_policies table. I can imagine frontend user management panel simply containing editable list of such policies for a given user. Also frontend could be improving the UX with some predefined policies or templates so that the user does not need to type jurisidctions/id/listings/id as it is done now in the AWS console.

Some problems to be solved:
1. it's not straightfoward to determine what listings a leasing agent has access to (leasingAgentInListings is no longer responsible for providing authorization to a user),
2. it's not straightforward to determine what jurisdictions auditor has access to

AD 1. One potential solution for this is to allow a leasing agent to list all listings so that they are displayed in his listings panel, but implicitly he can access applications only for a listings he has a policy for. When trying to access applications for other denied listings a generic 403 error message will be displayed. It also means that leasing agent needs to somehow know which listing he has access to (could e.g. be sent an invite email with appropriate listings URL in partners portal?)

AD 2. Same approach, create a policy to allow an auditor to list all listings across all jurisdictions, but make partners portal configurable via UI to always add a jurisdictionId query param to all queries so that auditor can switch between jurisdictions and have a clear list of listings for e.g. Alameda in there. This way if he/she choses a not allowed jurisdiction every access other than a list action on listings will yield 403 authorization error.

Also there could be some policies filling automation done e.g. when inviting a leasing agent we could still provide a list of listings but instead of creating an associated leasing_agent_in_listings table we now create rows auth_policies. Same when creating a new user account and giving access to owned applications etc.

This approach is a trade off between UX (sometimes a user will try to do something on a resource he/she can list but is not allowed to edit and will hit a 403 error) and having a lot of flexibility (basically every identity in the system and be allowed / denied everything).