System Initialisation

Problem Statement 1 

Current problem with Sunbird is any one can create a root-organisation, sub-organisation, user, add user to an existing organisation etc. Further, there is a cyclic problem at system installation time with regard to user and organisation creation. Creation of user requires organisation and creation of organisation requires user. Presently, this cycle dependency is avoided by creating organisation using Keycloak (SSO) admin user token.

Proposed Solution

After successful installation, use an 'initialisation' script to create a system admin (first) user inside Sunbird and Keycloak.

System Admin User Creation

Once system admin user is created, the system admin user can perform following actions:

• Root organisation creation (only by system admin user)
• Root organisation admin (orgadmin) user creation
• Another system admin (sysadmin) user creation
• Another system admin user removal

System admin user details can be stored in existing Sunbird user details table (i.e. user) or can be stored separately in a new table (e.g. sys_admin_user). Pros and cons of these two alternatives are mentioned below.

Alternative 1: Storing system admin user details in existing Sunbird user table.

Alternative 2: Storing system admin user details in a new table (e.g. sys_admin_user).

In Keycloak, system admin user details can be stored in existing realm or a new realm.

Alternative 1: Storing system admin user details in existing Keycloak realm.

Alternative 2: Storing system admin user details in new Keycloak realm.

System Admin APIs

1.  Create System Admin User

This API is to create a system admin user. API call to create first system admin user doesn't require any user authentication. API gateway key is used to secure this API until first system admin user is created after system initialisation. Once a system is initialised, it will update isSystemInitialised to true in system_settings table.

After a system admin user is created, subsequent calls to this API to create additional system admin users would require access token of a previously created system admin user in addition to API gateway key.

Method: POST

URL: /v1/init/system/user/create

Headers: Authorization, X-Authenticated-User-Token

Request Body:

{                
    "firstName": "string",
    "lastName": "string",
    "email": "string",
    "phone": "string",
    "password": "string",
    "username": "string"
}

2.  Create Root Organisation

This API is to create a root organisation. can be done using /v1/org/create api.  or we can provide a separate api for creating rootOrg. Both are having some pros and cons.

Alternative 1: Create root organisation using existing /v1/org/create API.

Alternative 2: Create root organisation using new /v1/init/root/org/create API.

Method: POST

URL: /v1/init/root/org/create

Headers: Authorization, X-Authenticated-User-Token

Request Body:

{
    "orgName": "string",
    "channel": "string",
    "description": "string"
}

3.  Create Root Organisation Admin User

Existing User Create and Assign Roles APIs need to be modified to allow creation of an organisation admin user by a system admin or another organisation admin user only.

System Initialisation Script

Sunbird will provide a system initialisation script to simplify the Sunbird setup process for adopters.

The script will take necessary input from user to complete system initialisation.

• System admin user details
  • Username
  • First name
  • Last name
  • Email
  • Phone
  • Password
• First root organisation details
  • Name
  • Description (optional)
  • Channel
• First root organisation admin details
  • Username
  • First name
  • Last name
  • Email
  • Phone
  • Password

The script will preform following operations:

• Create first system admin user
• Create first root organisation
• Create first root organisation admin user

Problem statement 2

During user creation, user is added to a root organisation identified by channel property. This channel value can come in Create User API request or can be inferred based on environment variable for default channel (i.e. sunbird_default_channel). The problem with this approach is one more environment variable needs to be set by any Sunbird adopter and particularly an unnecessary setting for an adopter planning to have only one root organisation. In case of a Sunbird adopter with multiple root organisations and environment configuration for Sunbird default channel with a different root organisation, user creations without channel can result in users being silently added to an unintended root organisation which is not desirable.

Proposed Solution

Remove the environment variable sunbird_default_channel. Every time channel will either come from request or system can take it from database based on below logic:

• Always first priority is for channel value coming in request. if user sends channel in request then that need to be validated, in case of invalid channel system will throw proper error message.
• If channel is not coming in request then system will check whether there is only one root organisation. If so then user is automatically assigned to that root organisation. In case multiple root organisations are present then a suitable error is sent requiring that channel be specified in User Create API request.

Open Questions

• Do we require a separate consumer group to secure system initialisation APIs?
• Portal signup needs to be modified to send the channel during new user creation.