Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To facilitate information sharing while ensuring each contributors true identity, we will establish, publicize, share, and use a standardized account definition.

...

Personas

Note: personas are in process of being built. Once in place, the links will be provided to those personas.

...

List project goals and the metrics we’ll use to judge success

Goal

Metric

Establish and document a standardized account schema and publish it in grcschema.org

Review and attain sign-off from the GRC schema governing body

Establish a set of APIs that utilize the standardized account schema

A UC-written application can interact with the API Gateway to establish trust and then share information

Build a frontend application that utilizes the standardized account via a set of APIs

Mapper / UCH 2.0 can establish trust and share PlantUML data which updates the federated database

and / or

Compliance Dictionary can establish trust and share term definitions that update the compliance dictionary database or federated dictionary database (TBD)

Current Challenges / Limitations

...

List the project milestones along with how that milestone can be successfully measured.

Number

Description

Success Measurement

TBD

Product Requirements

Use Cases

...

The following term definitions must be agreed upon to ensure all stakeholders have the same understanding and will use common descriptions when discussing / using these terms.

Term

Alternative Term

Definition

Examples

GRC Schema

Comments

Organizations

An entity, such as a company, an institution, or an association, comprising of one or more Person.

ServiceNow, IBM, ATT, NIST, YMCA

Organization

Accounts

Organizational Accounts

An organizational subcomponent for the purpose of encapsulating collections of users, data, billing, etc.

“Mapper Account”

“Research Account”

Account

Smaller organizations will likely only have one account. However, enterprises will require many accounts to ensure appropriate departments / business units are billed appropriately

Users

User Accounts

The unique identifier of a user / person for the purpose of authorization

dsmith@ibm.com

janev@att.com

User and Person

Requirements

Requirement

User Story

Importance

Jira Issue

Comments

Organizations - Own

Reference to the GRCschema definition => GRCschema - Organization

“Own” Organizations are specifically referencing a customer or partner wants to setup their own organization and update it

Ability to create and setup a new Organization with all required information as identified in the standardized account schema definition

As a customer or partner of UC I want to create a new organization so that I can start the process of onboarding new users

Status
colourRed
titlep1

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 my Organization for all relevant information identified in the standardized account schema definition

As a customer or partner of UC I want to update the organization I created to ensure the information is correct

Status
colourRed
titlep1

Note that currently Mapper 2.0 functionality does not allow an organization to be changed since once it is created it is now part of the published set of organizations and falls under the same discussion of governance on who has permission to make changes to an organization if in the federated database.

Ability to upload and change my Organization’s logo

As a customer or partner of UC I want to customize the look and feel of my organization by updating the logo so that it looks and feels like my organization

Status
titlep3

Ability to delete my 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

Status
colourRed
titlep1

If users can’t delete on their own, it is fine if UC deletes on their behalf and/or puts the organization into an inactive state for later deletion or archiving.

When a user onboards their account and initial user, they create an organization (if not existing), then link the account to that org, and user to the account. The organization cannot be deleted unless the account is deleted or reassigned to a different organization.

Organizations - Federated

This section is about the federated aspect of Organizations where any authorized user can make changes

Ability for researchers to submit a new Organization for approval

As a content contributor I want to submit a new Organization that I want added to the Federated Database so that the Federated Database is more complete

Status
colourRed
titleTBD

 

Who should be able to add Organizations to the Federated Database?

Will need some governance

Ability for researchers to search for existing Organizations (including by status)

As a content contributor I want to search for existing Organizations including by status (submitted, approved …) so that I am aware of its status and can take further actions

Status
colourRed
titleTBD

 

 

Ability for researchers to view, edit, and delete existing Organizations

As a content contributor I want to view, edit, and delete existing Organizations so that the Federated Database is more complete

Status
colourRed
titleTBD

 

 

Ability for reviewer(s) to validate and approve creation, updates, or deletes of Organizations

As a reviewer I want to review and approve the Organization details to ensure it has all the pertinent information

Status
colourRed
titleTBD

 

As is case in AD requests and Dictionary terms, need ability to set 0 to N number of reviewers in the business rules

 

Ability to check for duplicates

As a content contributor I want the system to automatically check for duplicates to ensure the Federated Database isn’t populated with overlapping redundant data

Status
colourRed
titleTBD

 

 

Ability to create a new Organization as private and maintain it as private

As a content contributor I want the Organization to be visible only to users in my organization so that no other organizations are able to access our private and/or proprietary content

Status
colourRed
titleTBD

 

 

Ability to submit a private Organization to the public

As a content contributor I want to make a private Organization public to help keep the Federated Database more complete

Ability to submit an updated Organization definition and keep the version and history

As a content contributor I want to submit a subsequent version of the Organization to go through the Organization Request process so that any changes can be tracked

Status
colourRed
titleTBD

 

If we allow changes, we’ll want to keep track of history. This seems a bit more straight forward than other areas.

Review Workflow

 

 

 

 

Ability for account administrators to setup business rules for validation of an Organization

As an account administrator I want to manage the submission and review workflow to best match the structure of my team so that we can submit Organizations as efficiently as possible

Status
colourRed
titleTBD

 

For some contributors, they might not want any review since the person submitting the Organization is the domain expert. Other accounts may want one level of approval

Ability to setup task owners as a person, role or group

As an account administrator I want to flexibly manage the assignment of tasks in the Organization definition workflow process to control the queue of work so that I can best manage the workload of my team

Status
colourRed
titleTBD

 

Above requirement was for the number of steps. This one is for who is assigned to those steps.

Indirect assignments like roles and groups makes it much easier to maintain and quickens onboarding / offboarding efforts.

Large clients need to have many people

Ability to submit unvalidated Organization Requests

As a content contributor I want to contribute Organizations that are automatically approved with no need for validation so that my Organizations can be quickly added to the Federated Database for use

Status
colourRed
titleTBD

 

These Organizations must be marked as “unvalidated” to help end-users know that those Organizations should be used with caution

Accounts

Reference to the GRCschema definition => GRCschema - Account

along with

GRCschema - Group

GRCschema - Team

GRCschema - Initiative

Ability to create and setup a new Account with all required information as identified in the standardized account definition

Status
colourRed
titlep1

Includes: name, phone number, and address

Ability to update an existing Account for all relevant information identified in the standardized account definition

Status
colourRed
titlep1

Ability to upload and change the Account logo

Status
titlep3

Ability to delete an Account

Status
colourRed
titlep1

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

Status
colourRed
titlep1

Ability to deactivate users assigned to an account

Status
colourPurple
titlep2

Ability to delete users from an account

Status
colourPurple
titlep2

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

Status
colourPurple
titlep2

Ability to create, update, and delete Teams and add/remove users to those Teams

Status
colourPurple
titlep2

Ability to create, update, and delete Initiatives and add/remove users to those Initiatives

Status
titlep3

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

Status
colourRed
titlep1

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

Status
colourRed
titlep1

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

Status
colourRed
titlep1

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

Status
colourRed
titleTBD

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

Status
colourRed
titleTBD

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

Status
colourRed
titleTBD

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

Status
colourRed
titleTBD

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:

  1. permissions to perform functions like delete users

  2. control contribution workflows

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

Open Questions

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

...