...
There must be a governance process around who can contribute, what can be contributed, and revocation of those rights otherwise we risk losing credibility as the authoritative source.
It is assumed that we put in place role-based access control (RBAC) for both the API Gateway and the Mapper/UCH 2.0 application to control who is allowed to perform various functions
One risk is that the establishment of organizations, accounts, and users may create a confusing onboarding and login experience driving prospects and customers away. The onboarding and login user experience must be made easy yet thorough to establish trust.
...
Requirement | User Story | Importance | Jira Issue | Comments |
---|---|---|---|---|
Organizations | Reference to the GRCschema definition => GRCschema - Organization | |||
Ability to create and setup a new Organization with all required information as identified in the standardized account definition | As customer or partner of UC I want to create a new organization so that I can start the process of onboarding new users | Includes: legal name, name, description, domain, phone number, email address, founded year, phone number, address, social address, and classifications (e.g., NAICS Code, SIC Code …) | ||
Ability to update an existing Organization for all relevant information identified in the standardized account definition | As a customer or partner of UC I want to update the organization I created to ensure the information is correct | Same as above | ||
Ability to upload and change the Organization logo | As a customer or partner of UC I want to customize the look and feel of my organization by updating the log so that it feels like home | |||
Ability to delete an Organization | As a customer or partner of UC I want delete an organization I created by mistake and start over so that I don’t get confused as to which organization is the right one | If users can’t delete on their own, it is fine if UC deletes on their behalf | ||
Accounts | Reference to the GRCschema definition => GRCschema - Account along with | |||
Ability to create and setup a new Account with all required information as identified in the standardized account definition | Includes: name, phone number, and address | |||
Ability to update an existing Account for all relevant information identified in the standardized account definition | ||||
Ability to upload and change the Account logo | ||||
Ability to delete an Account | If users can’t delete on their own, it is fine if UC deletes on their behalf | |||
Ability to invite additional users to an account | ||||
Ability to deactivate users assigned to an account | ||||
Ability to delete users from an account | If users can’t delete on their own, it is fine if UC deletes on their behalf | |||
Ability to create, update, and delete Groups and add/remove users to those Groups | ||||
Ability to create, update, and delete Teams and add/remove users to those Teams | ||||
Ability to create, update, and delete Initiatives and add/remove users to those Initiatives | ||||
Users / Persons | Reference to the GRCschema definition => GRCschema - User and GRCschema - Person | |||
Ability to register as a new user with all required information as identified in the standardized account definition | Includes all the basic user information defined on the User object includes first name, last name, middle name, and e-mail address | |||
Ability to register a user as a Contributor by supplying additional trust information | Includes how to contribute as (org, person, or both), two social addresses, and phone number. | |||
Ability to supply additional optional information to help further identify the user | Includes alternative names, aliases, additional email addresses, additional phone numbers, additional social addresses, postal addresses, | |||
Contribution Managment and API Protection |
|
|
| There needs to be a workflow in place to manage who can contribute, what they can contribute, and guardrails if broken to revoke rights |
Ability for UC to allow or revoke rights for an account to approve own users for contribution | As a UC Administrator I want to allow or revoke the ability of an account to determine who can contribute to the federated database so that UC can control the quality of the federated database | It could become burdensome on UC to do all the approving. Initially we can keep it simple where UC must always approve. In later releases, we introduce the toggle to allow customers to decide who on their teams can contribute | ||
Ability for an Account administrator to request that a user be allowed to contribute | As a UC Administrator I want to allow or revoke the ability of any user to contribute to the federated database so that UC can control who can contribute | If UC doesn’t allow an account to decide on their own, then there must be a request process | ||
Ability for an Account administrator to revoke or allow users to publish to the federated database | As an account Administrator I want to allow or revoke the ability of a user to contribute to the federated database so that I can control who on my team can contribute | If we allow an account, then account administrators should be in control. Some users will only be researchers and not need to contribute | ||
Ability for UC to revoke or allow users to publish to the federated database | As a UC Administrator I want to allow or revoke the ability of any user to contribute to the federated database so that UC can control who can contribute | Even if allow accounts or third-party application to control who on their team can contribute, UC must be able to revoke the rights of a bad actor | ||
Role Based Access Control | Not everyone can be an admin There are two areas we need to control:
The first is an obvious candidate for RBAC. But controlling contribution workflows initially “feels” like a set of toggles with a bit more meaning that purely a permission. | |||
Ability for UC to create, update, and delete a set of default / global roles | ||||
Ability for UC to turn on / off permissions within global roles | ||||
Ability for UC to add new permissions and include them in default roles | ||||
Ability for UC to designate which role is assigned to the initial user of an organization | ||||
Ability for UC to designate which role is assigned to subsequent users in an organization | ||||
Ability for account administrators to create, update, and delete a set of custom roles | ||||
Ability for account administrators to turn on / off permissions within custom roles | ||||
Ability for account administrators to assign roles to users | ||||
Ability for account administrator to determine which role is automatically assigned to new users |
...
List any open questions that come to mind throughout the lifecycle of this project
Question | Answer | Date Answered |
---|---|---|
Both the API gateway and the Mapper 2.0 application need RBAC. How can standardize on one implementation in two different products with two different tech stacks? | ||
Out of Scope / Future Functionality
...