Versions Compared

Old Version 6

changes.mady.by.user Manzarul Haque

Saved on

compared with

New Version 7

changes.mady.by.user Vinaya Kumar B

Saved on

Key

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

    Problem statement 1 : 

...

Problem Statement 1 

Current problem with Sunbird is any one can create a root-organisation, sub-organisation, user, add user to org etc. In long term this will impact system behavior.  Another cyclic problem is creating user required 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 required user.As of now we are handling organisation creation using keycloak requires user. Presently, this cycle dependency is avoided by creating organisation using Keycloak (SSO) admin user token.     Proposed

Proposed Solution

...

                After successful installation call , use an 'Initialisationinitialisation' script /curl to create a System system admin (first) user inside sunbird Sunbird and keycloak. Keycloak.

System Admin User Creation

Once system admin user is created, he/she the system admin user can perform following actions                        

...

:

  • Root organisation creation (only by system admin
  • Admin user for RootOrg : RootOrg admin user can be created only by system admin
  • Creation of another system admin : One system admin user can create another system admin
  • Removing system admin : One system admin can remove another system admin.

  Note: System admin details can store same as normal user or can be stored on different places all together.

Inside sunbird we can store this user details either in user Table or some new tables (sys_admin) both is having there own pros and cons.

          * Storing System admin details in user table: 

                Pros:  

                       * No need to maintain any new table. 

                       * System admin is a user itself , so logically it should be saved in user table.

              Cons:

                      *  It won't have all the access as normal user , We need to add unnecessary check on other api's. 

                     *  User search , here we need to hide system admin details.

                     * Open-saber should not store system admin user details.    

         * Storing System admin details in different table (Sys-admin)

                 Pros: 

                       * Details will be separate out from normal user

                       *  Easy to Manage their account and actions.

                Cons:

                       * Overhead of one more table management

Managing system admin user in keyclaok:

                If we allow system admin to do all operation as normal sunbird user can do then will create user under same realm other wise will create user another different realm , so that he/she should not be able to login.

Required api :

    1.  System init api

           This api will allow to create System admin user. First api call won't required any user authentication , it can take api gateway key as one level of security.Once one System admin is created then to create next system admin , caller need to provide first system admin auth token. Once system is initialized then it will update system-setting table with attribute isSystemInitialized  as true.

     Api details :  

             Post /v1/system/init

                Header : 

                               * Authorization 

                              * x-authenticated-user-token

              Request body :

                           {

                               "firstName": string // Mandatory 

                               "email" : string // Mandatory

                               "phone" : string // Mandatory

                               "password": string //Mandatory

                               "username": string //Mandatory

                         }

2.  Create RootOrg : 

...

  • 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.

ProsCons
  • No need for a new DB table
  • Existing code can be reused for system admin user CRUD operations
  • Code maintainability is reduced as behaviour of system and normal users can be expected to be different. e.g. Details of system admin may not be required to be stored in registry or shown in user search results


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

ProsCons
  • Code is easy to maintain as there is separation of normal and system admin users 
  • Additional development effort for maintaining new DB table


In Keycloak, system admin user details can be stored in existing realm or a new realm. Pros and cons of these two alternatives?

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:


Code Block
languagejs
{                
    "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.

                     * Creating rootOrg using Alternative 1: Create root organisation using existing /v1/org/create apiAPI.

                          Pros:

                                1.   No need to expose separate api 

                                 2.  Development time will be less

                         Cons:

                                1.  Need to have check based on request attribute. Example if isRootOrg true coming then check admin auth

                                2.  if any business logic changes for rootOrg creation it can have impact on org creation as well.

                    * Creating rootOrg using v1/system/rootOrg/create api  .

     Pros:

                                 1.  Easy to maintain access control  

                                 2.   Easy to maintain any business requirement changes for rootOrg creation

                       Cons:

                                1.  Need to have one more api

                                2.  initial development time will be little higher.

     Api details :  

           Post /v1/system/rootOrg/create

                Header : 

                               * Authorization 

                              * x-authenticated-user-token

                Request body :

                           {

                               "orgName": string // Mandatory 

                               "channel" : string // Mandatory

                               "description" : string // optional

                          }

  3. Add rootOrg admin:

            This api will allow system admin user to create a user and make that user as  rootOrgAdmin

Api details :  

      Post /v1/system/rootOrg/admin/create

                Header : 

                               * Authorization 

                              * x-authenticated-user-token

              Request body :

                           {

                               "firstName": string // Mandatory 

                                "lastName": string //optional

                               "email" :      string // Mandatory

                               "phone" :     string // Mandatory

                               "channel":   string// Mandatory

                          }

         Note : After making that changes will restrict  rootOrg creation , making admin for rootOrg from different api calls.

Proposed Solution 2:

       Sunbird will provide system init script. That script will take all necessary input to user and internally try to complete system initialization. 

  It will take following input:

  •   orgName
  •   channel
  •   orgDescription
  •   sysAdminFirstName
  •   sysAdminEmail
  •   sysAdminPhone
  •   sysAdminUserName
  •   sysAdminPassword
  •   rootOrgAdminFirstName
  •   rootOrgAdminEmail
  •    rootOrgAdminPhone

  It will preform following operations:

  •   Create a system admin user
  •   Create a rootOrg
  •   Create a user 
  •   Make that user RootOrg admin
  •   update system-config table with isSystemInitialized  as true

Note: Channel registration and hashTagId registration need to taken care during rootOrg creation.

Problem statement 2 : 

...

ProsCons
  • Reuse existing Org Create API which reduces development effort
  • Request body needs to be checked as well to restrict root organisation creation to specific user groups
  • Code maintainability is reduced in case requirements for root organisation and sub organisation creation diverge over time

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

ProsCons
  • Code is easy to maintain as there is separation in root and sub organisation creation flow
  • Easy to apply different access controls as API for root and sub organisation creation are separated
  • Additional development effort for supporting root organisation CRUD APIs

Method: POST

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

Headers: Authorization, X-Authenticated-User-Token

Request Body:

Code Block
languagejs
{
    "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.

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 body or can be set inside env (key : inferred based on environment variable for default channel (i.e. sunbird_default_channel). The problem with this approach is one more env need environment variable needs to be set and if some adopters having only one rootOrg then it's won't have much sense. If adopters having multiple rootOrg and due to some reason env is set with different rootOrg , then silently all user belongs to that rootOrg.

Proposed Solution :

   Remove the env 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 data base database based on below logic.:

  •   Always first priority is for  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 there only one rootOrg , if yes then assign user with that rootOrg , if having multiple rootOrg then ask user to pass the channel

...

  • 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.