Problem statement 1 :
Current problem with sunbird is any one can create rootOrg,suborg , user , add user to org etc. In long term this will impact system behavior. Another cyclic problem is creating user required organisation and creation of organisation required user.As of now we are handling organisation creation using keycloak admin user token.
Proposed Solution 1:
After successful installation call 'Initialisation' script/curl to create a System admin user inside sunbird and keycloak. Once system admin user is created , he/she can perform following actions
- RootOrg creation : Root org can be created 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 :
This 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 v1/org/create api.
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 :
During user creation , user rootOrg is identified by channel property. This channel value can come in request body or can be set inside env (key : sunbird_default_channel) . The problem with this approach is one more env need 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 sunbird_default_channel . Every time channel will either come from request or system can take it from data base 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 is there only one rootOrg , if yes then assign user with that rootOrg , if having multiple rootOrg then ask user to pass the channel
Open Question: How are we going to handle it during user creation from portal(website) ?