[Spike] Activate user

[mahalakshme]

User flow:

Users uploaded on Avni should receive their credentials only after they complete their training on Glific. So the flow for this keeping in mind to minimise the errors is:

• The data entry person will upload the user and catchment details as usual on Avni
• But the above users will be in deactivated form and should not receive credentials
• Once the users finish their training on Glific, Glific via web hook will call /activate on Avni during which users should receive the credentials
• The data entry person will monitor the webhook logs on a daily basis and for the failed calls will activate the users manually in Avni.

As is:

Currently activating or deactivating a user from webapp User page, activates/deactivates in Cognito as well, enabling the user to login. The user doesn't receive any credentials on activation.

Suggestion of Avni flow:

Step 1: Creating users in deactivated mode:

• Have a column in CSV file of 'Users and Catchments' called Active. Default value will be the configured one for the org. Can override by setting it to false or true.

Technical suggestion to achieve the above:

Set DesiredDeliveryMediums to empty list on user creation API to avoid sending SMS to the user

Step 2: Sending user credentials via SMS when activated:

• Need to send only when the 'Confirmation status' of the user in Cognito is 'Force change password'. No need to send if it is 'Confirmed'.

Tech suggestion:

1. Setup a Lambda trigger in RWB env alone to achieve this. The lambda should get activated when manually activated via Avni webapp UI or when a user is created in an activated state initially itself.
   Sample python code:

import boto3

# Initialize SNS client
sns_client = boto3.client('sns')

def lambda_handler(event, context):
    # Extract user details from the event
    user_pool_id = event['userPoolId']
    username = event['userName']
    user_attributes = event['request']['userAttributes']
    phone_number = user_attributes.get('phone_number')
    temporary_password = user_attributes.get('custom:temporary_password')  # Assuming stored as a custom attribute
    
    if not phone_number or not temporary_password:
        print(f"Missing phone number or temporary password for user {username}.")
        return

    # Compose the SMS message with credentials
    message = (
        f"Hello {username},\n"
        f"Your account has been activated.\n"
        f"Username: {username}\n"
...

2. In the 'Authentication methods' under 'Password Policy' update 'Temporary passwords set by administrators expire in
   ' to 365 days from 90 days.

AC:

• Make sure the above technical suggestion will work and suggest alternatives if any better available.
• The idea is to achieve the intended user flow without adding any features that are too specific for an organisation.
• Also suggest estimate for the above to identify if the above process has derailed from the previous estimates.

Inputs:

• from Avni trigger flow - training on Glific to avoid manual work

[1t5j0y]

Approach can be simplified using AdminCreateUser MessageAction:

• pass value as SUPPRESS initially when user is created to suppress sending of credentials.
• pass value as RESEND when credentials should be sent to the user. (Temp password will need to be set again at this time if we want to follow the existing pattern. If not, cognito generates a random password which is sent to the user.)

Work breakdown:

• Refactor user creation to cater to new 'sendCredentials' flag. Can optionally disable the user too but should not be required since credentials are not being sent to the user on creation.
• New external API to (optionally enable if disabled during creation and) trigger sending of credentials for an already existing user.

[mahalakshme]

Glific team finds authentication via SRP to be difficult from their Elixir backend. So 2 approaches we can think of

1. SRP auth: Let them expose the users to be activated via a API, Avni integration service will call that API to get the users and call Avni server to activate them. But this will result in an additional hop.
2. USER_PASSWORD_AUTH: create 'activating user' as a privilege and associate it with Glific api user and let them use USER_PASSWORD_AUTH. As part of this approach build a login api - that uses USER_PASSWORD mechanism for authentication - restrict the usage to only API users(somewhere we should be able to mark this).