Versions Compared

Old Version 1

changes.mady.by.user Rupam Baruah (Unlicensed)

Saved on

compared with

New Version 2

changes.mady.by.user Rupam Baruah (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Access Control Service(ACS)



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 :

  1. Mobile first - services, info, dashboard and reporting
  2. Localize - language (app, notifications, tracking, info)
  3. All-browsers and all-device compatibility
  4. UX/UI - "aam aadmi" design and not "silicon valley" design
  5. Accountability of gov employee - never compromise
  6. Standard Ontology - complaints, feedback, updates etc
  7. Should work-well in low speed / no speed networks also


Audience:

  1. Product Managers
  2. Developers
  3. Testers
  4. Co-creation partners
  5. Implementation Team
  6. Third Party(TP) integrators

Objectives :

Objective of access control service are listed as below.

  1. Authorization of user actions.


Functionality & Definitions :

Access control functionality basically works based on below points:

  1. Actions: Actions are events which is performed by an user. This can be a api end-point or Frontend event. This is MDMS master
  2. Roles: Role are assigned to user, a user can hold multiple roles. Roles are defined in MDMS masters.
  3. 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:

  1. Serve the applicable actions for a user based on user role(To print menu three).
  2. 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):

  1. Action authorization for multi tenant user.
  2. Module tenant mapping validation based on city-tenant master data from MDMS.


Feature List V1.2(Impacted from user changes):

  1. Actions,Role,& Role-action has to be simplified.(Denormalization)
  2. Support tenant level role-action

Interaction Diagram:


Image Added

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,

2.Simple with one call it can fetch all the masters from MDMS

1.Each time we need to make multiple api calls to post and search any master data.

2.Currently there is no auditing functionality

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

2. No change in future if level of child will increase

3. Wf also should be refer to System level Business service master

1. Currently every module has its own Business service master(Billing Svc)

2. Maintaining data in multiple master is difficult   

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 ,

2.Generating report as head wise is easy,

3.Makes simple system for integrator

1.Difficult to write query,

2.Query performance will be better

3. Have some issue in prod from the Report side

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,
and third party integration(Finance) will be much more easier.

Refer the diagram V1.1 below

Currently Collection and Finance integrations are difficult to support,

Revenue module, Collection,
Finance,
Report

P1

Multiple owners in Demand so that we can generate consolidated bill for all revenue module?

Enhancement

In Future Billing Service will support
User based consolidated bill for all business service, without this it will not be possible

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