Users are automatically registered to the hub upon first log in.

• User details are taken directly from their OIDC claims

An org can be made by any user.

• The user is set as the org's root user
  • The root user can only be changed by a super admin
• A Default Users permission group is created for the org and the user added to it
• The org is set in a pre-submission state, allowing the questionnaire to be handled separately and saved/modified in multiple sessions before submission.
• While in the pre-submission staste, the user can delete the org.
  • After approval, there is no strict delete available. SAs can soft-delete the org.
• Only required endpoints are available to orgs before they have been approved by an SA.

Root users can invite anyone to their org.

• Invitations are done via email so the invitor cannot tell if the user is already enrolled on the system just by adding them
• Invite links are JWTs containing the email, org id, invite type, and expiry
  • The actual link has a dummy url because it needs to be captured by the frontend.
• The link in the email must match the user's email they are logged into OICD with

Access to services is handled with an RBAC IAM system.

• Org root users can create groups and assign permissions to those groups.
• Any user can be invited to a group.
  • If the user already belongs to the org, they can be added directly
  • If the user does not belong to the org, an email invite can be sent instead
• Which permissions an org has available to them can be added by an SA, they default to none.
• Permissions can be either added manually by an SA, or registered automatically by the service
  • For clarity, this is added as options. Permissions are not automatically given to any org.

Endpoints designed solely for services to access auth with API keys

• API keys are generated on the hub when the service is registered
  • The key can be regenerated but is not returned on any endpoint after initial registration
• The service uses the key in a header when accessing the hub
• The primary endpoint for services is Can Act on Resource (CAoR) which additionally requires the user's OIDC header
• CAoR returns True if the user is in a group which has the permission to perform the given action, on the resource of that service, for that org
  • CAoR has a broad exception catch returning False so it fails-secure

There is decent test coverage.

• Happy path tests are done with a standardised function which ensures the endpoint has the correct auth level, returns the correct status code, and returns the correct data, in the correct shape.

All endpoints, their permission level, and their OpenAPI summaries are listed below:

• [GET] (/org): [Root User]: Get org details by ID.

• [POST] (/org): [User]: Create new organisation.

• [PATCH] (/org/questionnaire): [Root User]: Update questionnaire.

• [PATCH] (/org/status): [Super Admin]: Update status of organisation.

• [GET] (/org/users): [Root User]: Get email addresses of users of the organisation.

• [POST] (/org/user): [Super Admin]: Add user to the organisation.

• [DELETE] (/org): [Super Admin]: Delete organisation from the hub.

• [DELETE] (/org/self): [Root User]: Delete organisation from the hub as root user before it has been approved.

• [PATCH] (/org/root_user): [Super Admin]: Update the root user of the organisation.

• [GET] (/org/groups): [Root User]: Get all organisation IAM groups.

• [DELETE] (/org/user): [Root User]: Remove user from organisation.

• [GET] (/org/contact): [Root User]: Get contact for organisation.

• [PATCH] (/org/contact): [Root User]: Update contact for organisation.

• [GET] (/user/self/claims): [User]: Get current user OIDC claims.

• [GET] (/user/self/db): [User]: Get current user hub details.

• [GET] (/user): [Super Admin]: Get user hub details by ID.

• [DELETE] (/user): [Super Admin]: Delete user from hub by ID.

• [GET] (/user/self/orgs): [User]: Get all orgs the current user is a member of

• [POST] (/user/invitation): [Root User]: Send an email invitation for a user to join an org

• [POST] (/user/invitation/accept): [User]: Accept email invitation to join an org

• [GET] (/service): [Root User]: Get all services

• [POST] (/service): [Super Admin]: Register a new service.

• [PATCH] (/service/key): [Super Admin]: Regenerate service API key.

• [DELETE] (/service): [Super Admin]: Remove a service.

• [POST] (/service/permissions): [API Key]: Service endpoint for creating its own permissions.

• [POST] (/iam/can_act_on_resource): [API Key]: Used for services to check user access permission

• [GET] (/iam/group/permissions): [Root User]: Gets a list of permissions granted to a group

• [GET] (/iam/group/users): [Root User]: Gets a list of users assigned to a group

• [POST] (/iam/group): [Root User]: Creates a new group

• [PUT] (/iam/group/permission): [Root User]: Grants a permission to a group

• [PUT] (/iam/group/user): [Root User]: Directly adds a user to the group

• [DELETE] (/iam/group/permission): [Root User]: Removes a permission from the group

• [DELETE] (/iam/group/user): [Root User]: Removes a user from the group

• [GET] (/iam/permissions): [Root User]: Returns a full list of permissions

• [POST] (/iam/permission): [Super Admin]: Creates a new permission for a service

• [DELETE] (/iam/permission): [Super Admin]: Deletes a permission

• [POST] (/iam/permissions/search): [Root User]: Search list of permissions

• [PUT] (/iam/group/user/invitation): [Root User]: Send an email invitation for non-org member to join a group

• [PUT] (/iam/group/user/invitation/accept): [User]: Accept email invitation to join an org's group

• [PUT] (/iam/org/permissions): [Super Admin]: Grants an org access to permissions

• [GET] (/healthcheck): [None]: None