Initial Understanding Document - User Self Registration

---

{| border="1" cellpadding="2" Date Version Modified By Comments |- |09032016 || Draft r.1.0 || RajeshMadaye || Initial draft version prepared |- |09072016 || Draft r.1.1 || RajeshMadaye || Updated as per comments by Guido |- |09082016 || Draft r.1.2 || RajeshMadaye || Updated as per comments by Guido & LoginType Parameters |- |10202016 || Draft r.1.3 || RajeshMadaye || Updated document as per modified components. |}

1 Overview

This document is designed to understand the scope of requirement and to know expected results from system after new changes. This document will give more brief about functional requirement and user stories. This will have very limited information included about technical changes required into the new system.

2 Requirement Detail

This section will give more brief about functional requirement

Requirement: New user self-registration management.

• Current System:
  Today MasonSQL system does not support self-registration of new user. In case of new registration, MasonSQL administrator user will have to add new user manually into system and then share login credentials with end user to allow access.

• Future System:
  Future version of MasonSQL system should allow new user to do self-registration by doing request through MasonSQL login page and then MasonSQL system will verify login information and will send confirmation email or sms to new user with login credentials for first login.

• Use Case:
  1. User will click on "Register" button.
  2. User will get a form to fill required information.
  3. User will fill all required fields and will click on "Submit" button.
  4. User will get confirmation email or sms with temporary password.
  5. User should able to login to system using received credential detail.
  6. User will get option to change temporary password.

3 User & System Actions

{| border="1" cellpadding="2" width="50"|Sequence width="400"|User Action width="400"|MasonSQL System Action |- |1 |

• "User click on 'Register"

|-

2

|

• System should pop-up registration form ||

|- |3 |

• User can view registration form
• User will fill required detail
• User will click on "Submit"

|-

4

|

• System should validate if all information filled correctly
• Perform basic validation and verify if user-id is valid.
• System should enable user to some pre-defined group.
• If all verification passes then send confirmation mail to user email id with user-id/password detail if email setting is activated or else send sms if sms setting is activated.

|-

5

|

• User should get email or sms on given address or cell number.
• User should attempt to login using temporary password

|-

6

If first login then, system should force to change password at first attempt.

|- |7 || User changed password and should able to login. |- |8 || On login page, user should allow to change password. User will click on "Ho dimenticato la password ..." button. |- |9 || || System should open new form and ask user to enter login-id and to resolve captcha challenge. |- |10 || User will enter valid user-id and resolve captcha and click on submit |- |11 || || If valid user id and valid captcha solution then reset password and send new password to email or sms. |}

4 User Screens

4.1 Login page will be updated and new button(s) will be added to allow self-registration for new users.

• 4.1.1 New user registration button will be added with description [Registrazione nuovo utente]
• 4.1.2 Password reset button will be added (Planned in Later phase)
• 4.1.3 Look &fill on GUI will be changed later to make it more user convenient.
  

4.2 Registration form fields information.

• 4.2.1 Different registration forms

{| border="1" cellpadding="2" width="25"|Sr. width="400"| LoginType = syslogin width="400"| LoginType = Email |- |1 || Show "E-mail"& "Nome utente" both as mandatory fields on GUI registration page. || Show only "Nome utente" as mandatory fields on GUI registration page. "E-mail" is not required in this setting. |- |2 || Apply email validation to check "@" character for email field. || Apply email validation to check "@" character for "Nome utente" field. |- |3 || In this scenario, multiple users can be associated with single email id. But only user-id must be unique in any case.

Ie.
anagrafiche.email: anagrafiche.login
rajmad@yahoo.com : user-01
rajmad@yahoo.com : user-02
rajmad@yahoo.com : user-03
girishkhot@yahoo.com : user-04
ramkadam@yahoo.com : user-05 || In this scenario, one user can be associated with single email id. As in this case email id and login id both will be same. Also system will copy same login id internally as user id.

Ie.
anagrafiche.email: anagrafiche.login
rajmad@yahoo.com : rajmad@yahoo.com
girishkhot@yahoo.com : girishkhot@yahoo.com
samkad@yahoo.com : samkad@yahoo.com |- |4 || Email will be stored in anagrafiche.email field. || "Nome utente" will be a valid email address and it will be stored in anagrafiche.login field.

"Nome utente" will be a valid email address and it will also be stored in anagrafiche.email field. |- |5 || In this scenario, initial temporary password will be sent to anagrafiche.email field. || In this scenario, initial temporary password will be sent to anagrafiche.email field. As email field will always have valid email id for single login. |} {| border="1" cellpadding="2" Field Description Mandatory Field Validation |- |Nome: || First Name || Yes || Same as system allows today. |- |Cognome: || Last Name || Yes || Same as system allows today. |- |E-mail: || E-mail || Yes || Same as system allows today. |- |Accesso: || Login || Yes || Same as system allows today. |- |Cell. SMS || Cell. SMS || No || Same as system allows today. |- |Codice Fiscale: || Tax Code || No || Same as system allows today. |- |Descrizione || Description || No || Same as system allows today. |- |Indirizzo || Address || No || Same as system allows today. |- |Provincia || Province || No || Same as system allows today. |- |Città: || City || No || Same as system allows today. |- |Telefono: || Phone || No || Same as system allows today. |- |2° Telefono || 2nd Phone || No || Same as system allows today. |}

• 4.2.2 !LoginType = syslogin (Processing)
  • 4.2.2.1 New registration form will pop up to fill basic user information.
  • 4.2.2.2 User must enter "First name", "Last name", "Email", "UserID" as mandatory fields to register and all other fields will remain non-mandatory.
    
    

    User registration screen (Syslogin type)
• 4.2.3 !LoginType = E-mail (Processing)
  • 4.2.3.1 New registration form will pop up to fill basic user information.
  • 4.2.3.2 User must enter "First name", "Last name", "login-id" as mandatory fields to register and all other fields will remain non-mandatory.
  • 4.2.3.3 Login-id field should allow only valid email address as an input. To check validity, system will check "@" character in given login-id.
  • 4.2.3.4 Login id will be a valid email address and hence same email will be stored in anagrafiche.email and anagrafiche.login fields.
    
    

    User registration screen (E-mail type)

5 System flow understanding & Assumptions

• 5.1 System will switch registration based on LoginType defined in apache configuration file.
  Please visit 4.1 section in this document to get more detail on different document types.
• 5.2 System will generate temporary password as per below logic
  • 5.2.1 Temporary password will be created on top of current validation criteria and will include simple perl module Sting::Random with valid pattern (defined with apache parameter PasswordRandPattern (ie Cccsssn)
• 5.3 Clear old/non-active users from registry database.
  • 5.3.1 System should run ghost crontab script to keep cleaning old user records which have requested for registration but have not logged into system.
  • 5.3.2 In the current implementation we manage same useful fields in table
    • 5.3.2.1 "public.anagrafiche":- "last_change_password" - Date of last password change by user, otherwise forced to null value
    • 5.3.2.2 "previus_session_time" - Date of the previous session time
    • 5.3.2.3 "session_time" - While the user's login (or the time when the system force new login)
  • 5.3.3 Crontab script to will be created as ghost users when "last_change_password" is null and previus_session_time is null and now() - session_time > MaxTimeToConfirmUserRegistration
  • 5.3.4 SQL function public.change_password(text, text, boolean); will be reviewed for this requirement change.

5.4 Project Scope

This project is divided into multiple phases to keep incremental development towards business requirements and priorities. This section will give more brief about different phases identified to complete this project.

• 5.4.1 New user self-registration automation. (Phase-I)
  • 5.4.1.1 Allow end user to do self-registration to access system GUI.
  • 5.4.1.2 Apache configuration parameter "UserRegistration" will be set as "enable|disable" to make this registration for specific application.
  • 5.4.1.3 New user registration group "NewUserRegisterGroup" will be configured to assign preconfigured group name to any new user.
  • 5.4.1.4 User should get email or sms will be configured using "UserRegTypeMessage" parameter. So based on this user message template should get selected and message should be sent.
  • 5.4.1.5 User must activate login within next few days after registration. This date should be configurable value with parameter "MaxTimeToConfirmUserRegistration".
• 5.4.2 Open source captcha implementation for registration (Phase-II)
  • 5.4.2.1 Open source based captcha solution will be developed to restrict any robot registration.As of now we found below option, we will study more options and more suitable will be implemented for this system. Captcha implementation will be implemented in second phase of this project. In initial phase we will target to setup auto registration process. Below are three available options in Perl allows to implement captcha.
    • 5.4.2.1.1 https://metacpan.org/release/Captcha-reCAPTCHA
    • 5.4.2.1.2 https://metacpan.org/release/Authen-Captcha
    • 5.4.2.1.3 https://metacpan.org/release/Authen-PluggableCaptcha
  • 5.4.2.2 We have used Captcha-reCaptcha solution to implement it for self-registration form. This solution force end user to click on page and also allows to solve some challenges to make sure that end user is valid user and not a robot.
  • 5.4.2.3 Captcha-reCaptcha solution uses google api services to authenticate if user response is correctly resolved. We use Perl module Captcha::reCAPTCHA to resolve puzzle solved by end user.
  • 5.4.2.4 reCaptcha solution will require to generate new keys using gmail account. Those keys should be configured as "ReCatchaAPISecretKey" & "ReCaptchaAPISiteKey" in apache configuration file.
• 5.4.3 Reset Password (Phase-III)
  • 5.4.3.1 New button with [Reimposta password] (Reset password) will be added on login screen.
  • 5.4.3.2 Apache configuration parameter "UserPasswordReset" will be set a "enable|disable" to make this new user password for specific application.
  • 5.4.3.3 User should get email or sms with initial password will be configured using "UserRegTypeMessage" parameter. So based on this user message template should get selected and message should be sent.
  • 5.4.3.4 User must activate login within next few days after registration. This date should be configurable value with parameter "MaxTimeToConfirmUserRegistration".
  • 5.4.3.5 System will request the user login and Captcha, then will regenerate new temporary password and send it by e-mail.
  • 5.4.3.6 System will use apache configuration parameter "LoginType" to confirm where to send temporary password. (ie. To email-id or to login-id in case login id is valid email)
  • 5.4.3.7 Password reset will ask
    
    

    Reset password screen

6 Configuration Parameter Detail

Self-registration form allows end user to register to MasonSQL framework and below are configuration parameters to change the behavior of system.

{| border="1" cellpadding="2" Field Description Mandatory Field |- |UserRegistration | User Registration enable/disable:

• [Enable]: User registration will be enabled
• [Disable]: User registration will be disabled.

Administrator user should set "enable" value to allow end user to register to framework. | PerlSetVar UserRegistration "enable" |- |UserPasswordReset | User Password Reset enable/disable:

• [Enable]: User password reset will be enabled
• [Disable]: User password reset will be disabled.

Administrator user should set "enable" value to allow end user to register to reset password for given login. | PerlSetVar UserPasswordReset "enable" |- |LoginType | User Registration Type:

• [syslogin]: New user will be added into "Guest" group.
• [email]: Unique id-mail will be used as a login ID

| PerlSetVar LoginType "syslogin" |- |NewUserRegisterGroup | User registration default group name:

• [Guest]: Any new user will be added into "Guest" group.
• [Admins]: Any new user will be added into "Admins" group.

Administrator user should use valid group name for this parameter. | PerlSetVar NewUserRegisterGroup "Guest" |- |UserRegTypeMessage | User registration sms or email notification configuration.

• [email]: End user will get temporary password as email.
• [sms]: End user will get temporary password as sms. "Cell. SMS" field will be mandatory on form.

User will get notification only if correct email or phone number has been provided. | PerlSetVar UserRegTypeMessage"email" |- |PasswordRandPattern | Registered user random password format:

• c - Any lower case Latin [a-z]
• C - Any uppercase Latin [A-Z]
• N - Any digits [0-9]
• . - Any of the above
• S - A character "salt" [A-Za-z0-9./]
• B - Any binary data
  
• ! - A punctuation character [`~! @ $% ^ & * () -_ + = {} [] \ :;" '. <>? / #,]

| PerlSetVar PasswordRandPattern "Cccsssnn" |- |MaxTimeToConfirmUserRegistration | The maximum time for the new user confirmation in days:

• [days]: number of days in digit (ie 7, 15, 30, 60)

| PerlSetVar MaxTimeToConfirmUserRegistration 7 |- |ReCaptchaAPISecretKey || reCaptcha API site key generated for domain.
This key will be used to validate reCaptcha at server side.
|| PerlSetVar ReCaptchaAPISecretKey '6LchdQgUAAAAAL9Ui' |- |ReCaptchaAPISiteKey || reCaptcha API secret key generated for domain.
This key will be used to generate Captcha widget at client side.
|| PerlSetVar ReCaptchaAPISiteKey '6LchdQgUAAAAAK' |}

7 Open Items / Query Log

{| border="1" cellpadding="2" width="50"|No. width="400"|Query width="75"|Status width="400"|Comment |- |1 || Rajesh: How system should behave in case email-id given by user does not exists.

Possible option in such case is,

1. We should keep cleaning user login database by doing some additional handling to clean users who have not logged in since long back duration. Either we can remove those user or we can handle deactivate flag for those users.

2. Another way is to ask user to login to system within next 07 days from registration. So after first login within first 07 days will activate user account or else default user account will be created in in-active state.

I would like to know your comment on this behavior. || Closed || Guido: In the current implementation we manage same useful fields in table "public.anagrafiche":
- "last_change_password" - Date of last password change by user, otherwise forced to null value
- "previus_session_time" - Date of the previous session time
- "session_time" - While the user's login (or the time when the system force new login) So we can use a crontab script to delete ghost users when "last_change_password" is null and previus_session_time is null and now() - session_time > MaxTimeToConfirmUserRegistration

You can look the SQL function public.change_password(text, text, boolean); |- |2 || Guido:
But here there is a danger that an attacker can cause damage by forcing the change password to unsuspecting users, just because he knows the users' e-mail addresses.
Your opinion on this? || Closed || Rajesh:
1. We are giving one level of security by providing captcha. So it will prevent user to use robot for this attack up to some extent.

2. We can apply some backend logic to prevent max_reset_attempt for specific LoginID or for specific email-id within specific time frame. (ie. User can attempt to reset password for "rajesh" user maximum 03 times in 24 hours.)

Please do let me know your thoughts on this. |}