User account management

Target release TBD

Epic https://sioux.atlassian.net/browse/VAPP-9
Document status ANALYZED
Document owner Han Ho
Designer vu.thai (Unlicensed)
Tech consultant Chien Nguyen
Tech lead Thinh Kieu

Objective
To provide the capability of managing accounts in the VAPP system.
Success metrics
Goal Metric

Assumptions


Requirements
Jira
System Requirement
Issue
Online authentication
The VAPP system supports “Login with Gmail”. However, users cannot
sign up by themself, only users created by the User account management
feature can sign in to the system.
This feature also requires developing the Sign in and Sign out procedures References:
MOBILE for the system.
1  https
& CMS
The VAPP system can have more authentication options for users in the  https
future.
Wireframe:
 https://www.figma.com/file/slJKrmQUWP2njr0GMCESJw/Virbac-
App?node-id=29%3A11218
 Auto authentication
To improve user-experiences, once logging in successfully, if the
credentials don’t change or users haven’t signed out, then users don’t need
to provide the id and password next time access to the system.
When the credentials changes or the user has signed out, the user has to
enter the credentials again.
For WP1, we will implement a simple security layer:
 An access token is valid for 720 hours
 We will store the user’s credentials to local
MOBILE
2  When launching the app, if it’s online, the app will log in again to
& CMS
expand the access token
o If auto-login fails (token is expired), the app will log out
For future versions, there are several tips to increase the security level of
the system when auto-authenticating such as:
 We won’t store the user’s credentials, but store refresh tokens
 We only provide shorter-lived access tokens
 We use refresh tokens (or refresh token rotation) to expand tokens
every time doing auto authentication
 When signing out, we revoke all refresh tokens

Offline authentication
In offline mode, the application do the authentication based on stored id
tokens.
References:
If the stored id tokens are invalid or expired, the application won’t allow
3 MOBILE  https
users to use the application.
secur
To renew the id tokens, users can do authentication again when the
application is in online mode.
For the WP1, an id token is valid for 24 hours.
 Roles-based access control
The VAPP system uses a roles-based access control strategy to control the
permissions of a user in the system. In which:
 A user can be assigned to 1 or many roles. A user’s roles list is
mutable.
 A role contains 1 or many permissions. A permissions list of a role
is mutable.
 Based on the gained permissions, a user can access and use features
of the CMS and the mobile application.
 Based on the gained permissions, an API call can be processed in
MOBILE the backends.
4
& CMS  The permissions can be valid or invalid within a condition. For
example: if the customers are synced to Virbac database, only
admins can modify the customers. However, if the customers aren’t
synced, sale reps can modify their own customers.
To verify permissions of a user, the CMS and the mobile application will
use the Application authorization feature.
To verify permissions of an API request, the backends will use the API
authorization feature.
To update roles and permissions, the system will use the Roles and
permissions management feature.
Application authorization
When doing online authentication, the applications will specify the
corresponding claims to able to get corresponding permissions of a user
from returning id tokens.
Each application should have an access permission which defines whether References:
a user can sign in to the application.  Role-
MOBILE
5  For example: access:mobile or access:cms. contr
& CMS
Based on the permissions (or rights) described in each feature, users can  Perm
see the corresponding UI/UX. user-
 For example: Without a create:customer permission, users
cannot see the “Customer creation” option in the applications.
Specific roles and permissions will be defined in other specific
requirements/features.
 API authorization
When doing online authentication, the applications will specify the
corresponding claims to able to get corresponding permissions of a user
from returning access tokens.
APIs which access to specific resources will require corresponding
permissions. For example: create:virbacProduct,
MOBILE
6 edit:virbacProduct, delete:virbacProduct, view:virbacProduct,
& CMS
etc.
Only applications that link to the APIs can gain the permissions and use
the APIs.
To access the APIs using third-party tool such as Postman, we can do the
authentication from our applications to get access tokens, then use the
access tokens for these tools.
Admin and Sale rep roles
MOBILE For WP1, there are two basic roles who are Admin and Sale rep.
7
& CMS  Admin can access the CMS system.
 Sale rep can access the Mobile system.

Roles and permissions management

In roles and permission management, users can:
 manage roles
 assign or remove roles from/to a user.
When managing a role, users can do:
8 CMS  Role creation
 Role edition (add or remove permissions)
 Role deletion (remove the roles from all users)
 Role view
The changes will effect to the tokens in next time users doing
authentication.
Root account
Root account is a default account of the CMS system. A root account has
some following basic information:
 username: root
9 CMS  password: root
There will be a required form to update email and change the default
password of a root account for the first time signing in to CMS.
A root account has only one permission which is to create new admin
accounts.
10 CMS User account management Note 1: The
In customer management, users can do: Question: CR
 Account creation References:
 Account edition  https
 Account deletion
 Account view
When a new account is created, an email will be sent to the user’s email
address to verify and reset the default password.
User account data model:

 The data model will be updated based on the requirements of

authentication and authorization procedures.
 The email address can be the company’s Gmail only
 The user_name and password field are not necessary because we
will sign in by Gmail connection
 The country and version are the same (see more in the Localized
users feature)
 Added new fields: Display name.
 CRM id is “the customer id to link a sale rep to its list of
customers”
o The kind of value should be “1, n” instead of “1” because
the relationship between sale reps and customers are one-to-
many. One sale rep will manage many customers and one
customer only belongs to one sale rep
o Admins might not have any customers or CRM ids
Rights:

NB: The View and Edition of a customer by a User Account should be

 filtered by the CRM id.

Open Questions
Questio
Answer Date Answered
n

Out of Scope
