Problem Statement
Related Jira Task - SB-11433 - Getting issue details... STATUS
{
"jti": "<random_string>",
"iss": "<issuer_id>",
"sub": "<user_external_id>",
"aud": "<base_url>",
"iat": 1498556656,
"exp": 1498560256,
"name": "<name_of_the_user>",
"state_id": "<channel_name_of_the_tenant>",
"school_id": "<pre_created_school_external_id>",
"roles": ["<role1>", "<role2>"],
"redirect_uri": "<base_url>/resources"
}
The v2 Single Sign On(SSO) API allows user to login to DIKSHA if a user account is already present and creates an account for the user, if it is not present.
As of now, name, school_id, roles fields are only used in creation flow and they are being ignored in subsequent SSO logins of the users.
The requirement is, if any of the fields(name, school_id, roles) change at the state database, it should reflect in DIKSHA as well during subsequent logins of the existing SSO users.
| Change in field | Required Action |
|---|---|
| name (firstName) | Update the first name of the user (User Update API) |
| school_id (orgExternalId) | Add the user to the new school and remove from existing school, if any (Add Member to Org and Remove Member from Org APIs) |
| roles | Assign the new roles to the user replacing the existing ones (Assign role API) |
Content service has the SSO API and the other consumed APIs are at learner service.
- Content service has access to the latest data(name, orgExternalId, roles) from SSO Payload
- Content service has access to following data from DIKSHA - firstName, organisationId, roles
While name can be compared against firstName, for org and roles comparison, equivalent organisationId of the orgExternalId should be available.
Approach 1
Use Organisation Search API - Content service can query learner service for org details using orgExternalId
| Pros | Cons |
|---|---|
| Simplest and inline with current approach. At present, there's a user read call to fetch the user details. This call would be a similar one to fetch the linked organisations' details. | For each SSO login, one extra API call (Org Search API) overhead will be added even if there's no change in the data in payload |
Approach 2
At present, only linked organisationId is available at user details in elastic search at learner service. The corresponding orgExternalId field can also be added to user details, so that all requisite details(name, orgExternalId, roles) to compare the data against payload would be available in the response of user read call itself.
| Pros | Cons |
|---|---|
| No extra API calls are needed | When external id of an organisation is updated, user sync of all the linked users has to be done to make sure orgExternalId is latest in elastic search for each linked user |
Approach 3
On successful SSO login, content service can push the payload into a kafka topic, from which an LMS samza job can read the data and do the needful(Approach 1).
| Pros | Cons |
|---|---|
| No overhead to SSO API. Comparison of fields and updation, if needed, happens asynchronously. | It's very rare for the payload data of a particular user to change. Though the execution is asynchronous, still there's an overhead to the system to perform this check for each request |