...
Alternative 1: Storing system admin user details in existing Sunbird user table.
Pros | Cons |
---|
- 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).
Pros | Cons |
---|
- 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?
Alternative 1: Storing system admin user details in existing Keycloak realm.
Pros | Cons |
---|
- System admin user can also login to Sunbird Portal
- Less development effort as existing Keycloak realm is reused
| - Sunbird portal and APIs could involve code changes to customise UI specific to system admin user
|
Alternative 2: Storing system admin user details in new Keycloak realm.
Pros | Cons |
---|
- Restrict system admin users to login to Sunbird Portal as their needs are different and require another portal for administration
| - Additional development effort to support another Keycloak realm
- In case some APIs (e.g. org admin creation) require to be supported for both system admin and org admin users then two realms need to contacted to authenticate the user
|
System Admin APIs
1. Create System Admin User
...
Alternative 1: Create root organisation using existing /v1/org/create API.
Pros | Cons |
---|
- 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.
Pros | Cons |
---|
- 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/root/org/create
...