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.
...
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 label 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
...
* Authorization
* x-authenticated-user-token
Request body :
...
* Authorization
* x-authenticated-user-token
Request body :
...
* Authorization
* x-authenticated-user-token
Request body :
...
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 It will take following input:
* orgName
* channel
* orgDescription
* sysAdminFirstName
* sysAdminEmail
* sysAdminPhone
* sysAdminUserName
* sysAdminPassword
* rootOrgAdminFirstName
* rootOrgAdminEmail
...
- 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) ?