Assigning user roles and RBAC proposal

[erikguntner]

Overview

As we’re wrapping up Section 1 one aspect of account management we still need to tackle is assigning users to their specific roles (e.g. Guest, Host, Coordinator, Admin) and Role Based Access Control. This will help set the groundwork for the role-specific features we will be developing in Section 2 and beyond.

I’ve broken down the requirements for this into a couple of high-level key features:

• Assigning the user to their specific role upon signing up
• Setting up decorators on routes to allow or deny access to certain roles
• limiting access to specific routes on the frontend based on user role

These requirements can be broken down further depending on the approach we decide to take.

Approach 1: Using AWS Cognito user groups

AWS Cognito allows you to define user groups within which you can add users and define permissions for each user type. Once a user is added to a group/s you can access the list of groups from the id token returned from AWS when signing up. We can then control access to routes on our server by creating a decorator that decodes the token and check the groups against the ones allowed for that resource.

Pros:

• Easily define groups in AWS
• Access groups from a token so we don’t have to make database queries every time we want to check role access
• Define permissions for AWS resources as well

Cons:

• We have to write our own decorators for our routes

Resources:

https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-user-groups.html

Approach 2: Using Flask RBAC

Flask RBAC is a library that provides some helpful functionality for setting up and utilizing RBAC. The library shows you how to set up tables for roles and users, and provides the decorators that control access to routes.

Pros:

• Comes with the functionality necessary to integrate RBAC with SQLAlchemy
• Comes with decorators to protect routes

Cons:

• Database transactions every time we hit a route with an RBAC decorator
• We can’t define IAM roles for access to AWS permissions
• The library hasn’t been updated in 3 years. In JS land that seems like a long time, but maybe that’s not the case for Python libs

Resources:

https://flask-rbac.readthedocs.io/en/latest/

Approach 3: Hybrid Approach

We use AWS Cognito groups to assign roles and define access to AWS resources, and we use Flask RBAC to assign users to roles in the database and protect routes. This approach covers a lot of functionality but requires us to track roles and groups across the database and in AWS, which could add some complexity.

I’m leaning towards Approach 1. I think cutting back on DB transactions is valuable and since AWS provides us with a way to define groups we might as well use it. I also don’t foresee creating our own decorators being a massive on taking. Interested to hear others thoughts and opinions!

[paulespinosa]

Which AWS resources would a role have direct access to?

[paulespinosa]

Using Cognito groups seems like a good choice because user management is self contained within Cognito.

Be sure to note somewhere that the token passed from the client needs to be validated/verified in the decorator. AWS has a Lambda example showing the use of python-jose to verify JWTs.

[paulespinosa]

Regarding the process around managing the roles: Since this app has clearly defined roles already (Host, Coordinator, Guest), managing the Cognito user groups (roles) is going to be a one time event for each environment, right? Would the app need any other roles such as a "customer support" role or tenant administrator role? Who/how will the roles be managed in Cognito?

Do we have separate Cognito accounts for each environment (dev, qa, prod, etc)?

[erikguntner]

@paulespinosa great questions!

Which AWS resources would a role have direct access to?

I can't say for certain right now. We'll have to determine that based on the resources they'll need access to and the privileges we want to grant them. For example, reading and writing to RDS, S3, access to SNS, etc.

Be sure to note somewhere that the token passed from the client needs to be validated/verified in the decorator

Good point!

...managing the Cognito user groups (roles) is going to be a one-time event for each environment, right? Would the app need any other roles such as a "customer support" role or tenant administrator role? Who/how will the roles be managed in Cognito?

By "one-time event" are you asking if the groups are editable or adjustable? User groups can be added, edited, or removed at any time and not just when you initialize the Cognito client. I could potentially see us needing more distinct roles down the line, but I can't say for sure what those are right now. One thing I've been reading about when it comes to RBAC is parent and child relationships and I'm not sure how that would play into defining roles in Cognito. I believe a developer with access to the AWS console would manage the roles.

Do we have separate Cognito accounts for each environment (dev, qa, prod, etc)?

This is something I've been thinking about as well, and I think goes hand in hand with configuration tasks being worked on right now. It might be a good idea to set up different clients for different environments so we aren't messing with production users during development or testing, and we could pre-populate environments with test users.

[paulespinosa]

@erikguntner

By "one-time event" are you asking if the groups are editable or adjustable? User groups can be added, edited, or removed at any time and not just when you initialize the Cognito client. I could potentially see us needing more distinct roles down the line, but I can't say for sure what those are right now. One thing I've been reading about when it comes to RBAC is parent and child relationships and I'm not sure how that would play into defining roles in Cognito. I believe a developer with access to the AWS console would manage the roles.

Yes, generally, I was trying to imagine how the process and procedure of adding, editing, and removing would work. A Project Manager would likely request and approve of a role and define the actions to take for its implementation. The actions would be:

• Manipulate (add/edit/remove) the user group in Cognito (via a script?)
• Move existing users in or out of the role (Cognito user group) (via a script?)
• Modify access controls to features on the frontend to include/exclude the role
• Modify access controls on the API to allow/forbid the role

These steps might need to be bundled together in a release.

[ju1es]

thanks for writing this up Erik this is awesome. i'm with y'all on the first approach. and we could incrementally build off of it if we need to consider the third approach.

Do we have separate Cognito accounts for each environment (dev, qa, prod, etc)?

This is something I've been thinking about as well, and I think goes hand in hand with configuration tasks being worked on right now. It might be a good idea to set up different clients for different environments so we aren't messing with production users during development or testing, and we could pre-populate environments with test users.

looking at boto3.client(...) in auth_controller.py, we could definitely wrap and inject this. so at runtime we could specify whether it's using an instance that interfaces with production, dev, or local user's auth creds.

[paulespinosa]

A note about something I was reading and needs to be scrutinized carefully:

We might not need to implement a decorator but a function instead. If I understand the connexion security documentation correctly, it will take care of authorization for us if we write the security requirements into the OpenAPI spec and implement a function to return the scopes within the token.

The function still needs to validate the token is authentic, though.

If using OAuth 2.0

With Connexion, the API security definition must include a x-tokenInfoFunc or set TOKENINFO_FUNC env var.

x-tokenInfoFunc must contain a reference to a function used to obtain the token info.
...
The referenced function accepts a token string as argument and should return a dict containing a scope field that is either a space-separated list or an array of scopes belonging to the supplied token. This list of scopes will be validated against the scopes required by the API security definition to determine if the user is authorized.

If using Bearer Authentication (JWT)

With Connexion, the API security definition must include a x-bearerInfoFunc or set BEARERINFO_FUNC env var. It uses the same semantics as for x-tokenInfoFunc, but the function accepts one parameter: token.

In the OpenAPI spec
The path items should have a Security Required Object specifying the allowed scopes (in our case role).

For the Cognito case
The user groups (we call these roles, right?) a user belongs to is in the token's cognito:groups claim.
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html

The access and ID token both include a cognito:groups claim that contains your user's group membership in your user pool.

scope is a type of claim. So for the Cognito case, the function can return the values for cognito:groups.

It so happens that the code base is already almost there:

HomeUniteUs/api/openapi_server/_spec/openapi.yaml

Line 463 in fdf9f07

x-bearerInfoFunc: openapi_server.controllers.security_controller.requires_auth