Skip to content

Latest commit

 

History

History
107 lines (93 loc) · 5.36 KB

FRS-MOSIP-Sub-Systems.md

File metadata and controls

107 lines (93 loc) · 5.36 KB
Raw

Table Of Content

Sub-Systems

1. UIN Generation

MOSIP generates a pool of UINs before the registration process and stores them. The number of UINs to be generated in a pool depends on a configuration to be done by the country depending on the peak registration requirements. UIN generation service will receive a request by Registration Processor to get a UIN. The service responds with an un-allocated UIN from the generated Pool. When the pool reaches a configured number of minimum UINs, MOSIP generates another pool of UIN.

The UINs generated follow the following policies:

  1. UIN should not contain any alphanumeric characters
  2. UIN should not contain any repeating numbers for 2 or more than 2 digits
  3. UIN should not contain any sequential number for 3 or more than 3 digits
  4. UIN should not be generated sequentially
  5. UIN should not have repeated block of numbers for 2 or more than 2 digits
  6. The last digit in the number should be reserved for a checksum
  7. The number should not contain '0' or '1' as the first digit.
  8. First 5 digits should be different from the last 5 digits (E.g. 4345643456)
  9. First 5 digits should be different to the last 5 digits reversed (E.g. 4345665434)
  10. UIN should not be an ascending or descending cyclic figure (E.g. 4567890123, 6543210987)
  11. UIN should be different from the repetition of the first two digits 5 times (E.g. 3434343434)
  12. UIN should not contain three even adjacent digits (E.g. 3948613752)
  13. UIN should not contain ADMIN defined restricted number

2. Configuration Server

MOSIP has a centralized config server where all the configuration elements are saved, including the platform config and ID Object schema. The Central config server provides following functionality:

  1. It provides functionality to read XML files and Property files
  2. It helps to manage all the configuration files stored at a centralized location in Git
  3. It provides a functionality to change the property for a micro-service, it can reflect the changes dynamically without redeploying the micro-service.
  4. This component allows all the configurations to come from a central server

Please refer the configuring MOSIP section in Getting Started guide for more details on the configuration server

3. Audit Manager

The Audit Manager component receives a request to audit and store data, validates if the request is from an authorized source, securely store the requested data and respond back with an acknowledgement of storage (Success/Failure). This component will also ensure non-auditable data is not stored. Upon receiving a request to store audit logs with the input parameters the audit manager performs the following steps:

  1. Validates if all required input parameters have been received as listed below for each specific request

    • Audit Event ID - Mandatory
    • Audit Event name - Mandatory
    • Audit Event Type - Mandatory
    • Action DateTimestamp - Mandatory
    • Host - Name - Mandatory
    • Host - IP - Mandatory
    • Application Id - Mandatory
    • Application Name - Mandatory
    • Session User Id - Mandatory
    • Session User Name - Mandatory
    • Module Name – Optional
    • Module Id - Optional
    • ID - Mandatory
    • ID Type - Mandatory
    • Logged Timestamp - Mandatory
    • Audit Log Description - Optional
    • cr_by, (Actor who has done the event) - Mandatory
    • cr_dtimes, (When this row is inserted into Database) - Mandatory

  2. Validates if the Audit Request is not for one of the exempted events as listed in the Exempted Audit Event List/Table

  3. Time Stamp (format: yyyy-MM-ddThh:mm:ss) and Unique Audit ID are generated by the Audit manager component for each Audit REQuest

  4. All the input parameters received are stored in the audit Database

  5. PII data as listed below is not stored

    • Name
    • DOB
    • Contact Number
    • Citizenship
    • Legal Status
    • Gender
    • Race/Ethnicity
    • Any Government Identification Number

  6. Responds with the acknowledgment to source

    • Success
    • Failure

  7. Raises an alert in case of an exception

3.1 Log Manager

Log manager provides following functionalities:

  1. Generate logs across the application
  2. Store generated logs in configured location
  3. Support for reading the logger configurations through as external file
  4. Support addition log level to a particular logger dynamically

4. LDAP / Authorization (WIP)

MOSIP system can handle Authorization across core services and restricts access to Web-services as per the roles defined below:

  1. OTP manager: To be defined
  2. SMS Notification Manager API : To be defined
  3. Email Notification Manager API : To be defined
  4. Software Updater API - Master Data : To be defined
  5. Software Updater API - Configurations : To be defined
  6. Software Updater API - Public Keys : To be defined
  7. Crypto Service API : To be defined
  8. Key Manager API : To be defined
  9. Master Data APIs (All Create/Update/Delete) : To be defined
  10. UIN Generator : To be defined
  11. Audit Manager : To be defined
  12. OTP Notification Service : To be defined
  13. ID Repo Service : To be defined