Data Sharing and User management updates

[lboeman]

Updates for sharing data and user management. Still a work in progress. Updates as of this moment:

• Updated adding/removing roles from users to depend on the 'create role grants' permission.
• Added check for rbac permissions on a role before sharing with users outside the callers org.
• Added check for role granted to external user before allowing adding rbac-based permissions to a role.
• Create a new user if they have a valid auth0id and their email is validated.
• Add a procedure and endpoint for listing the current user's information (uuid, org_id, org name)
• Add a procedure/endpoint for listing users that are granted roles from your organization. Again, the 'create role_grants' permission is checked here.

Introduces #144

I've used the create 'role_grants' permission as a sort of admin flag here, Users could be allowed to remove roles from themselves without a permissions check by comparing their auth0id with the mapping. We could alternatively apply a uuid to each role_user mapping, and have permissions to control the crud operations on each mapping. Allowing users to remove themselves from the role would be complicated though, as a permission to delete the specific user_role mapping would make the role user specific.

[lboeman]

@alorenzo175 I think I've touched upon all of your comments. I'm going to need to fix the tests, which is failing in part due to the demo module not containing new storage_interface functions. To implement the the lookup user by email logic working for data sharing. For this we'll need to store a token for the management API. Do you have any insight into how to persist a JWT for the api to communicate with Auth0, so we're not retrieving a new JWT for each request?

[alorenzo175]

For the management API, we should be able to enable M2M communication with a new auth0 app for the sfa API. Then we can use the client id and secret to authenticate with the management API and store the token in redis (perhaps in a different db from the queue).

[lboeman]

Additional updates on this PR since last review:

• On user creation, add a role with permissions to read the role and user and add it to the user. This Role exists in the Unaffiliated organization so that no other users may be granted update role permissions.
• add a 'Read this role' permission to new roles by default.
• Allow sharing of permissions with 'read' action outside organization, so that roles can still be shared.

[lboeman]

Okay I think this is ready. In sumarry:

• Creates an 'Unaffiliated' organization. This is the default organization for new users, and default roles and permissions are owned by this organization. (user can read itself, and the role containing permissions to read itself).
• Allows admin users to grant roles outside their organization as long as the grantee's organization has accepted the TOU.
• Roles contain a permission to read themselves on creation.
• Reading a single role now includes a list of user ids that have been granted that role.
• Creates users if they have a valid token and email is verified. Will have to update the dashboard for better handling. Currently if a user signs up but does not have a verified email, a json decode error is thrown in many cases.

[alorenzo175]

:+1: