# User Source
This document provides a comprehensive overview of user source. The insureMO platform has many user sources, which are used to manage different types of user data, user passwords, etc.
For example:
* The LIMO platform uses dorami to store user information.
* The GIMO platform uses GIMO APP URP.
* The GIMO member service is used to store customer information.
* The Japan `jp-member-service` is used to store customer. information in the Japan cloud.
We have set users' source ids according to these different user sources, and the corresponding relationships are as follows:
* mo: insureMO default URP, we call it Platform URP.
* limo: LIMO dorami.
* platform: GIMO platform uses GIMO APP URP.
* member: member service.
* jpmember: Japan jpmember service.
## Features:
### User Source Security Management
insureMO provides the user source security config feature.
We support setting different password policies, two-factor authentication policies, token policies, and user lockout policies based on different user sources. If you want to use this config, please contact insureMO foundation team first,because some user sources don't support all the features.
#### Default Password Rules
By default, a password must meet all of the following rules whenever it is set or changed — setting a password from the activation email, changing your own password, or setting/resetting a password by an administrator:
| Rule | Default Requirement |
|------|---------------------|
| Minimum length | 8 characters |
| Maximum length | 20 characters |
| Lowercase letters | at least 1 (`a-z`) |
| Uppercase letters | at least 1 (`A-Z`) |
| Digits | at least 1 (`0-9`) |
| Special characters | at least 1 (`@ $ ! % * # ? & ^ - _ + = /`) |
| Account name | the password must not contain the account name |
| Weak passwords | passwords on the built-in weak password blacklist are rejected |
| Password history | the new password must not be the same as any of the last 5 passwords |
| Account lock | after 5 consecutive failed login attempts, the account is locked until an administrator unlocks it |
When an administrator resets a password with a random password, the generated password always satisfies the current rules.
Password expiry is optional. When a validity period is configured (for example, 90 days), the user is notified before the password expires, and the configured action applies after expiry — either blocking login until the password is reset, or requiring a new password at the next login.
The password policy can be customized per user source or per tenant. The effective policy is resolved in this order: user source configuration > tenant configuration > default rules. The customizable items include the password length range (1–100), required character types, password history limit, password validity period, account lock threshold, and an optional custom password rule (regular expression) that replaces the length and character type checks. Regardless of the customization, the account name check and the weak password blacklist always apply.
### Get token via different User Source
When a user calls the CAS service to obtain a token, the user needs to pass in the user's source ID. If not passed in, mo is used as the default user's source ID, and the user must exist in the insureMO default URP service.
When the user enters the `user_source_id` as platform, the user must exist in the GIMO APP URP service. The CAS service will call the GIMO APP URP to verify the user's password.
When the user enters the `user_source_id` as member, the user must exist in the member service. The CAS service will call the member service to verify the user's password.
### User Source Limit in Gateway
After the user's password passes the verification, the generated token will be bound to the user's source ID. After the gateway verifies the validity of the token, it will verify the user's source ID.
If it is mo or platform, which are the default selectable URPs of the platform, then the user can access the APIs registered in the gateway. After this verification, URP permission verification is still required.
If it is member, limo, or jpmember, the generated token cannot access other tenant APIs registered in the gateway by default, but can access the APIs registered by the current tenant itself. These APIs need to be specified to be accessible by users with a user's source ID of member.
As shown in the following figure, the following parameters need to be configured in the API attribute at the gateway level, or this parameter can be added in swagger. We recommend using swagger for configuration.
After the gateway verifies the user's source ID, it still needs to go to the URP corresponding to the API to verify whether the user has the permission to access the API. If the user does not have the permission, a 403 Forbidden response will be returned.
Currently, the platform has three URP services. Which URP is used by the current API for authentication is the choice of the API itself. The person registering the API needs to be clear about which URP the caller is using. Generally, the user's source ID should match the URP.
For users' source ids, such as member, limo, and jpmember, the choice of URP is determined by the project development team, and the user's source ID and URP need to be configured properly at the API level.
The URP service provided by insureMO Foundation. APIs registered in the gateway default to using this service for API authentication. After the API Provider grants access to tenant, all users under the current tenant have the permissions to these APIs.
APP URP (that is, GIMO APP URP). Currently, APIs registered in the gateway using the static routing method basically use GIMO URP for authentication. We no longer recommend the static routing method in the future.
The URPv2 service is provided by insureMO Foundation. This service is an upgraded version of the insureMO default URP service. The insureMO URPv2 service provides permission management services for all offerings on the platform.
* Below is how the `user_source_id` works in CAS service and gateway service.
```mermaid
graph TD;
A[User Initiates API Call] --> B[Go to CAS Service to Obtain Token]
B --> C[Check if user source id is Passed In]
C -- Yes --> D[Determine the User's Service Based on user source id]
C -- No --> E[Default user source id is mo, Determine User in insureMO Default URP Service]
D --> F[CAS Service Verifies User Password]
E --> F
F -- Password Verification Passed --> G[Generate a Token Bound to user source id]
F -- Password Verification Failed --> H[CAS Service Returns Password Error Message]
G --> I[Gateway Verifies Token Validity]
I -- Valid --> J[Gateway Verifies user source id]
I -- Invalid --> K[Return 401 Unauthorized]
J -- mo or platform --> L[URP Permission Verification]
J -- member, limo, jpmember --> M[Check if the API Belongs to the Current Tenant and Allows Access by the Corresponding user source id]
M -- Yes --> L
M -- No --> N[Return 403 Forbidden]
L -- Has Permission --> O[Invoke API]
L -- No Permission --> N
```