Access Control Service(ACS)
- Version:
- V1 (Jan-2017 To Dec-2018)
- Audience:
- Objectives :
- Functionality & Definitions :
- Feature List V1:
- Feature List V1.1(Impacted from user changes):
- Feature List V1.2(Impacted from user changes):
- Interaction Diagram:
Context:
DIGIT is API based Platform here each api is denoting to a DIGIT resource.
Access Control Service(ACS) main job is to Authorize end user based on their roles and provide access of the DIGIT platform resources.
Version:
V1 (Jan-2017 To Dec-2018)
- V1.1(Jan-2019 To March 2019)
Guidelines :
- Mobile first - services, info, dashboard and reporting
- Localize - language (app, notifications, tracking, info)
- All-browsers and all-device compatibility
- UX/UI - "aam aadmi" design and not "silicon valley" design
- Accountability of gov employee - never compromise
- Standard Ontology - complaints, feedback, updates etc
- Should work-well in low speed / no speed networks also
Audience:
- Product Managers
- Developers
- Testers
- Co-creation partners
- Implementation Team
- Third Party(TP) integrators
Objectives :
Objective of access control service are listed as below.
- Authorization of user actions.
Functionality & Definitions :
Access control functionality basically works based on below points:
- Actions: Actions are events which is performed by an user. This can be a api end-point or Frontend event. This is MDMS master
- Roles: Role are assigned to user, a user can hold multiple roles. Roles are defined in MDMS masters.
- Role-Action: Role actions are mapping b/w Actions and Roles. Based on Role,Action mapping access control service identifies applicable action for role.
Feature List V1:
- Serve the applicable actions for a user based on user role(To print menu three).
- On each action which is performed by an user, access control look at the roles for the user and validate actions mapping with the role.
Feature List V1.1(Impacted from user changes):
- Action authorization for multi tenant user.
- Module tenant mapping validation based on city-tenant master data from MDMS.
Feature List V1.2(Impacted from user changes):
- Actions,Role,& Role-action has to be simplified.(Denormalization)
- Support tenant level role-action
Interaction Diagram:
Feature |
Category |
Why |
Current |
Impacted module |
Priority |
Remove GL codes from Billing service (faster roll out) |
TechDebt |
Gl codes belongs to finance system, hance finance module should own it. |
Unnecessary data configuration for each revenue module. |
PT, TL, Collection, Finance |
P1 |
Move all the master to MDMS (faster roll out and audit) |
TechDebt & Enhancement |
1.Maintainability and Default auditing, |
1.Each time we need to make multiple api calls to post and search any master data. |
PT,TL,Collection |
P1 |
Business service should be a common master at system level, and it should have a capability of n level children |
Enhancement |
1. Single source of truth for the data |
1. Currently every module has its own Business service master(Billing Svc) |
Collection,WF, PT, TL |
P2 |
Roundoff of bill amount should be standardized at the platform level (Keep it to 2 decimal) |
New Feature |
Each revenue module is writing the logic for round off the bill amount. |
Each revenue module is writing the logic for round off the bill amount. |
PT, TL |
P1 |
Make Income as +ve and deduction as -ve in demand (Ease the apportioning logic) |
Enhancement |
1.Easy to understand , |
1.Difficult to write query, |
PT,TL,Collection,Finance |
P1 |
Revenue module flow should be standardized at platform level for all known use-cases(A Step to apply and pay) |
NewDesign |
Reports, Dashboard, |
Currently Collection and Finance integrations are difficult to support, |
Revenue module, Collection, |
P1 |
Multiple owners in Demand so that we can generate consolidated bill for all revenue module? |
Enhancement |
In Future Billing Service will support |
Current system takes only one owner |
PT,TL |
P3 |
Single api to create demand and get the bill for the same |
Enhancement |
Reduce multiple call to create demand and bill for all the revenue module |
Currently each revenue module integrating with demand and bill api |
NA |
P3 |
First Level abstraction of calculation |
New / Enhancement |
|
|
PT,TL |
P2 |
Billing migration |
Impacted |
|
|
|
P1 |
Collection migration |
Impacted |
|
|
|
P1 |