Migration of G2C services to Datahub platform Public Services Grievance Redressal Division, Cabinet and Department of IT and Telecom, MoIC

CONTENT OF THE TERM OF REFERENCE BACKGROUND INFORMATION 5

OBJECTIVE 5

SCOPE OF WORK 6

Migration 6

Warranty, Support, Maintenance & Change Management 7

Backup and Recovery 8

TECHNICAL REQUIREMENTS 9

Software User Requirements 9

Audit Trails and Time Series Data 10

Legacy data Migration/Correction & upgrading of database 11

Platform and Technology 11

Security Features 13

Hardware Requirements 13

Concurrency, Browser Compatibility and Bandwidth Optimization 13

Authentication Management 13

Development Methodology 14

Annual Maintenance Contract 15

Confidentiality of Data 16

Conformity with Standards 16

Use of Source Code Management Tools 16

Ownership of Source Code and other Intellectual Property 16

Obsolescence 16

Project Development Team 17

Project Governance 17

TERMS AND CONDITION- GENERAL 17

Presentation by the Procuring Agency 17

Collaboration, Partnerships with Foreign Firms & Subcontracting 17

Patent and Copyright 18

Quality of Work 19

Timely Completion 19

Confidentiality of offer 19

Time Frame for completion 19

Implementation Arrangements 19

MINIMUM REQUIREMENTS FOR THE BIDDER 20

Staffing Requirement 21

ANNEXURE 23 Annexure I - List of services/systems to be migrated to datahub platform 23 Annexure III - Change Request Contract (CRC) 37 Annexure IV - ToR for Training of master trainer 39 Annexure V: Checklist of Project Deliverables 40

Annexure VI: Man-Day Rates for the Change Management for the 1st Year 40

Annexure VII – NON DISCLOSURE AGREEMENT 41

Annexure VIII : SSO and API Invocation flow (language independent) 43

TECHNICAL TERM OF REFERENCE (ToR) PROJECT NAME: Migration of G2C services to DATAHUB

1. BACKGROUND INFORMATION

The Department of Information Technology and Telecom, Ministry of Information and Communications has initiated a datahub project with the objective to seamlessly share the most common availed data among RGoB information systems through a common data sharing infrastructure. This initiative will ultimately pave the way for integrated service delivery within the government and ease service delivery for citizens. Under the initiative, we have enhanced security for a number of integration points from the department of census and civil registry such as the view citizen details Application Program Interface (API) and passport service API as proof of concepts using a single sign on (SSO) feature. This feature will further ease citizen access to services wherein citizens will have to register only once for a digital identity and then have the ability to avail all other public services linked to that authentication mechanism. This will make accessing services across government for citizens that much easier while not undermining security of critical databases in the government.

As a part of this engagement, we also want to enhance the existing data sharing system deployed for the G2C services while adopting a centralised system to create data services through the data exchange platform and to carry out the enhancement work for the identified G2C services.

2. OBJECTIVE

The main objective of this integration work is to seamlessly share the most common availed data among RGoB information systems through a common data sharing infrastructure. It will ultimately pave the way for integrated service delivery within the government and ease service delivery for citizens. Integrating G2C services with SSO and datahub will further ease citizen access to services wherein citizens will have to register only once for a digital identity and then have the ability to avail all other public services linked to that authentication mechanism. This will make accessing services across government for citizens that much easier while not undermining security of critical databases in the government.

3. SCOPE OF WORK

DITT invites Tender for migration of current G2C services to datahub platform in API based environment and enable single sign on (SSO). The scope of the work is as under:

3.1. Migration 3.1.1. The list of services to be migrated is mentioned in annexure I.

3.1.2. Prepare Software Requirement Specifications (SRS) or Functional

Specifications (FS) document and Software Design document (SDD).

3.1.3. Upgrade the G2C services to consume data using API in datahub. 3.1.4. All citizen facing services must be integrated with Identity Server for

SSO 3.1.5. The vendor shall test the upgraded services in staging environment

only. 3.1.6. The migrated services should be configurable by the DITT to enter

the consumer secret and key once the system has been approved and pushed to the production environment. The system should be able to dynamically generate the access token using the application credentials.

3.1.7. Strategize, design and successfully deploy the systems at GDC with appropriate server/node architecture based on factors such as number of concurrent users, traffic, bandwidth etc.

3.1.8. Provide comprehensive training to datahub team on the operation of the software, backup, configuration, etc. The vendor has to also provide the user manual on backup, configuration of server nodes, operation of the software etc.

3.1.9. Provide complete source code along with software drivers and other system files needed for installation and execution of the package. The list of deliverables is mentioned in annexure V.

3.1.10. Provide detailed installation and operations/user manual. 3.1.11. Provide detailed technical manual incorporating the System Design

and other technical features incorporated in the software package. 3.1.12. Provide free support for a period of one year from the time of

acceptance of the software by DITT and carry out revisions, if any, arising out of bugs or minor changes during the said one year period (Warranty support).

3.1.13. Provide services for Change Request on demand of the client whenever major changes are required in the system under CRC.

3.1.14. Implement and provide the software with all the standard security features inbuilt to ensure integrity of data. The Vendor will be responsible for the recovery of the data that is tempered because of lack of standard security features. The software package must have user access roles through which can assign or revoke rights of a user to a function or data.

3.1.15. Provide the Plan for recovery, if the software package or the database fails, which includes managing backups of the database and the package itself. Perform necessary recovery of the system when needed.

3.1.16. The vendor will be also required to setup the local machine environment, staging environment and production set up systems to test and back up the life system or package in case of disaster.

3.2. Warranty, Support, Maintenance & Change Management The vendor must provide free following supports for a period of 1 year from the time of acceptance of the software by the DITT.

3.2.1. During the above mentioned warranty period, the vendor will be responsible for making minor changes, as well as to fix the bugs, if any.

3.2.2. If there is a major change (as defined in sl no. 3) in the requirements of the system, the vendor must provide post implementation support under a Change Request Contract (CRC) for five years from the date of acceptance of the software package by DIT/Procuring Agency. The specific terms and conditions for CRC are included in Annexure III.

3.2.3. The changes will be considered major if the change brings about a major impact on the database or adds more input screens. These changes will be handled under the Change Request Contract (CRC) while the minor modifications of fields within an existing screen or changes having minor or no impact on the database will be handled under the Warranty support for 1 year from the date of acceptance of the developed system.

3.2.4. During the warranty period, the vendor must involve its key staff like System Analysts and Sr. Developers or any other technical member of the team to resolve the issue or bug that arise during the life of system.

3.2.5. During the production of the G2C services, the bugs will be classified into two categories: Critical and Non-Critical. The Critical bugs are those which freeze the systems and the normal

functioning of the procuring agency’s system or any related service Agency’s system to malfunction. This also includes the application not being able to consume the API subscribed by the client application. Other bugs will be classified as Non-Critical. Critical bugs must be fixed within 24 hours from the time of reporting from the client in any form of media. However, in some exceptional cases, the vendor may negotiate for time extension if acceptable to the client. The Non-critical bugs should be fixed within 5 working days.

3.3. Backup and Recovery

3.3.1. There should be atleast 5 days backup maintained for every system within the server environment and a weekly backup at an offsite data recovery center. The synchronization of the Databases will be scheduled and a hot backup will be done on a daily basis.

3.3.2. The problems other than hardware failure will be addressed by the

vendor under warranty support for 1 year from the user acceptance. The system failure due to hardware failure will be addressed by the vendor under the schemes mentioned above once the new hardware is replaced by the client.

3.3.3. The vendor will also provide adequate training to the System Administrator from the Procuring Agency so that routine checks and basic recovery can be handled in-house. In addition, the vendor must address the following during the warranty period:

3.3.3.1. The backup of the database should be taken on daily and/or

weekly incremental basis. 3.3.3.2. Full backup of relational database and source code files

should be taken on monthly basis whenever changes take place.

3.3.3.3. A full (cold) backup should always be kept in a safe location.

3.3.4. The vendor must also ensure that adequate training is provided to the System Administrator so that procuring agency can handle the backup and recovery issues in-house after the expiry of the warranty period.

4. TECHNICAL REQUIREMENTS

4.1. Software User Requirements The requirement is to migrate the existing G2C service/systems to the data hub platform in API environment from the current web services. The migration of service/systems have to entail the following transaction flow diagram as shown below:

The list of services/systems to be migrate is mentioned in Annexure I.

4.2. Audit Trails and Time Series Data Audit trails will be necessary in the proposed system wherever necessary, which will inform when and who has accessed, created or modified data. The system should also be able to capture and preserve time series data so that information is not lost with passage of time and repeated updating.

4.3. Legacy data Migration/Correction & upgrading of database During the migration of G2C services to the new datahub platform, necessary data migrations and updates shall be carried out by the vendor to optimally run the services in the platform.

4.4. Platform and Technology

The service migrate from G2C to datahub platform should run on technologies listed in the Table 1: Data Hub Technical specification and Table 2: Existing Platforms and Software Deployed for the G2C systems

4.4.1. The migrated system should work in TWAN environment with appropriate built-in facility to capture and store data at centralized database at [GDC/DITT]. In absence of LAN connectivity, the system should be also accessible through Internet.

4.4.2. The core development platform should be implemented in JAVA.

The necessary inputs and the possible outputs that could be generated from the system should strictly conform to what has been finalized in the SRS document and subsequently the prototype.

4.4.3. The system must also make use of any popular front-end UI

frameworks [such as Twitter Bootstrap, Foundation, Google Material

Design, Semantic UI and etc] wherever there is a need to change

the front end of the migrated services.

4.4.4. SSO and API Invocation: To integrate client applications with the Datahub platform, Vendor needs an unique client id and secret for each and every application. The vendor has to also provide login redirect url and logout redirect url (if it has separate urls for login and logout) to DITT Datahub Team and make a request to register the client application in datahub side. The SSO and API Invocation flow (language independent) is attached as annexure VIII for vendor reference.

4.4.5. Once DITT Datahub team provided the Client ID and Client secret, developers can start integrating the application with sso platform. Please refer the OIDC SSO Flow diagram. For more details on SSO and API Invocation flow (language independent), refer to the attached documents documents along with this TOR

4.4.6. Cost of Licenses: The cost of licenses for the production server, will be borne by procuring agency. However, any other licenses as required during the development and migration of G2C services must be borne by the SDV. The software developer should provide the necessary indemnity to DITT, MoIC that it possesses bona fide

licences for usage of the front-end and back-end tools for development and testing purposes.

Table 1: Technical Specification for datahub

Component Platforms/ software

a. Individual departmental application

Application Java applications using struts framework 2.X; Application server: Jboss (latest stable version with LTS)

Database MySQL (Latest stable version with LTS)

Operating Systems: CentOS (Latest stable version with LTS)

b. Central Systems

Single Sign-on Solution All the systems should be integrating with the Datahub SSO platform and adhere to the Datahub standards

RDBMS MySQL (Latest stable version with LTS)

Table 2: Existing Platforms and Software Deployed for the G2C systems

Component Platforms/ software

b. Individual departmental application

Application Java applications using struts framework 1.X; Application server: Jboss 6.x

Database MySQL 5.x

Operating Systems: Cent OS 6.x

b. Central Systems

Portal Framework Solution Liferay 6.1.2 for building the G2C Portal (www.citizenservices.gov.bt)

Single Sign-on Solution Central Authentication Service (CAS)

Directory Server Solution OpenDs LDAP is used to store the user credentials of all the users (citizens and agency users)

RDBMS MySQL 5.x

Enterprise Services Bus (ESB)

WSO2; The e-services which are exposed by other applications running in the other departments will be integrated with the portal through ESB.

Reporting Solution Jasper Report

Web Service Engine AXIS

MVC Platform Struts

4.5. Security Features After the services are migrated to the new platform, the services shall be scanned by the BtCIRT with their vulnerability testing tools. The vendors shall be responsible to fix any vulnerabilities related to the migrated services within the project contract period. The vendor must also suggest additional security components as required in the G2C services to the existing security features.

4.6. Hardware Requirements

The service migrated should be operational on existing infrastructure of the respective agencies and that of the Govt DC.

4.7. Concurrency, Browser Compatibility and Bandwidth Optimization dat

Since, bandwidth of the network through which the application is going to be used is low; the migrated services must run optimally on a PC, Tablet and Mobile device connected to even the lowest internet or network bandwidth. The migrated G2C services must be compatible with and well rendered in Microsoft Internet Explorer 11 and above, Mozilla Firefox 50.0 and above, and Google Chrome 55.0 and above. The migrate G2C services must run on any screen sizes. Using modern UI frameworks for responsive design is mandatory.

4.8. Authentication Management The migrated G2C services shall be signed using IS server in the datahub to achieve single sign on (SSO). This feature will ease the citizen in accessing the services wherein citizens will have to register only once for a digital identity and then have the ability to avail all other public services linked to

that authentication mechanism. This will make accessing services across government for citizens that much easier while not undermining security of critical databases in the government.

5. Development Methodology

The vendor should strictly follow the SCRUM development methodology during the project development.

5.1.1. The vendor shall carry out assessment on existing list of services

and technologies to optimally allocate or determine the product backlogs. It shall also consist AS-IS and TO-BE workflow.

5.1.2. The product backlog must consist of related services or processes of different services to efficiently carry out process re-engineering where possible.

5.1.3. The vendor shall carry out user requirement of each product backlog separately and get SRS sign off to initiate the implementation of first sprint.

5.1.4. The vendor shall also get sign off on each test cases and present the each sprint backlog integrated with datahub staging environment. This will help in better user acceptance of the system.

5.1.5. Some of guidelines that needs to be followed during the SCRUM

methodology are as follows: 5.1.5.1. The vendor should identify and provide an account for the

project manager in the SCRUM management tool (recommended Jira or Trello)

5.1.5.2. The single point of contact during the entire project should be the product owner of the development team.

5.1.5.3. The vendor should identify the sprint duration and should work closely with the project manager in presenting/reviewing the deliverables at the end of every sprint.

5.1.5.4. During the development, each service has to be to reviewed on an average, at least 3 times/sprints

5.1.6. To enable efficient agile scrum development methodology, the

vendor should follow the DevOps architecture where all the source code should be maintained and versioned at a cloud/local repository.

5.1.7. During the enhancement of the services, it should be first tested in the development machines of the vendor by the testers from vendor’s side following which access will be provided with the staging environment of the datahub where the services should be thoroughly tested before releasing it to the production environment with live data.

5.1.8. Only successfully tested product backlog in the staging environment shall be migrated and released in production environment.

5.1.9. After the user acceptance test succeeds, the systems has to be deployed for live operation at the GDC by the vendors.

5.2. Annual Maintenance Contract The vendor must provide quotation for AMC for next 5 years to carry out following task

5.2.1. The backup of the database should be taken on daily and/or weekly incremental basis.

5.2.2. Full backup of relational database and source code files should be taken on monthly basis whenever changes take place.

5.2.3. A full (cold) backup should always be kept in a safe location. 5.2.4. The vendor is also responsible for updating version of the

software/systems license used for this over 1 years free warranty. The vendor should include this cost in their AMC for next five years.

5.2.5. The vendor should ensure that all the systems are operational and functioning without any bugs or errors. Any errors, bugs, or downtime in the system should be taken into consideration depending upon the criticality of those systems.

5.2.6. The vendor should also ensure that all the versions of the systems are up to date to the latest LTS. Any updates in the systems related to security related vulnerabilities should be patched /updated /upgraded with the highest priority.

5.2.7. During the AMC period, the vendor must ensure that they have the capability to handle the issue . The vendor must maintain its key staff involved during the migration of G2C services to Datahub platform, so that they have the capability needed to ensure that critical bugs and change requests can be taken up during the life of the system.

5.2.8. During the AMC period, the issue and bugs will be classified into two categories: Critical and Non-Critical. The Critical bugs are those which freeze the systems and the normal functioning of the procuring agency’s system or any related service Agency’s system

to malfunction. This also includes the application not being able to consume the API subscribed by the client application. Other bugs will be classified as Non-Critical. Critical bugs must be fixed within 24 hours from the time of reporting from the client in any form of media.. However, in some exceptional cases, the vendor may negotiate for time extension if acceptable to the client. The Non-critical bugs should be fixed within 5 working days.

5.3. Confidentiality of Data Since some of the legacy data handled by the vendors during the migration of G2C services will be classified and restricted in nature, all the team members from the vendor’s side must sign a Non-Disclosure Agreement (given in Annexure VI) with DITT/Procuring Agency.

5.4. Conformity with Standards The G2C services to be migrated to data hub should strictly adhere to the following standards:

5.4.1. Electronic Government Interoperability Framework (eGIF) standards. (http://egif.moic.gov.bt)

5.4.2. Information Management Security Policy of RGoB 5.4.3. OIDC Oth2 authentication 5.4.4. e-Government policy [draft]

5.5. Use of Source Code Management Tools

The vendor must manage its source codes through a source code management tools like Subversion (SVN) and GIT or any other equivalent source code management tools, so that many programmers can work in parallel without duplication of work. It will also be a useful tool to track previous versions of the codes and will be useful for debugging purposes.

5.6. Ownership of Source Code and other Intellectual Property

The Procuring Agency will be the rightful owners of the Source Code and all Intellectual Property associated with the system and they will have full rights over the ways they can use these resources. The information system so developed will be the sole property of the DITT/Procuring Agency or any agencies designated by them. The list of project deliverables is indicated in Annexure V

5.7. Obsolescence The vendor undertakes to continuously and unfailingly advise the Client of new technologies (hardware & system software) in regard to the Solution during the currency of this Contract. If the Client decides to introduce any such new

technologies in replacement of the Solution or along with the Solution or as the case may be, the work that may arise therefrom shall be considered beyond the purview of this Contract. The Client shall enter into a change request contract (CRC) for the purpose; provided that such work scope is not being covered under the licence agreement.

5.8. Project Development Team The minimum requirements for the Project Development Team from the vendor’s side are as specified in Part 5 of this document. The vendor may propose any additional professionals that may be required for the successful implementation of the project with proper justifications.

5.9. Project Governance The management structure for the project has been proposed in this document based on identification of specific players, their responsibilities and the degree of interaction required between them during execution of this project. Under the project, the DITT/Procuring Agency proposes to set up the working groups to aid the implementation of the project. In this regard, the Project Manager, which is to be fielded by the vendor, is fully responsible for conducting a thorough study of the project, and accordingly come up with a comprehensive project governance structure (including the teams from the vendor’s side) that is mutually acceptable by the DIT/Procuring Agency.

6. TERMS AND CONDITION- GENERAL 6.1. Presentation by the Procuring Agency

The Client (DITT/Procuring Agency) will identify a suitable date for making a presentation to clarify the requirements before the submission of bids. The dates will be announced on the DITT website (http://www.dit.gov.bt) one week prior to the date of presentation. Further, bidders can approach Procuring Agency or DITT if required for further clarification on the requirements during office hours. This will reduce the gap of misunderstanding the requirements which becomes a trailing factor and reason for escalation of cost of the project at the later stage. Therefore, it is important for the bidders to understand the requirements in the first place. DITT/Procuring Agency will not be held responsible for escalation of implementation costs incurred by wrong estimation done by the vendor owing to inadequate understanding of the requirements.

6.2. Collaboration, Partnerships with Foreign Firms & Subcontracting The local Vendor is encouraged to go into long term partnerships with reputed international firms based on resource sharing and transfer of technology.

6.2.1. The Vendors who wish to enter the partnerships with foreign firms must ensure proper transfer of technology to the extent of building the local capacity for long term sustainability of the local vendor. Project based tie-ups and short term partnerships are not encouraged because it doesn’t ensure the long term sustainability of the project. The partnership should last at least till the end of the 1 year warranty.

6.2.2. A vendor, who wishes to terminate partnerships with foreign firms due to unavoidable circumstances, must ensure that there is competent local capacity already built, so that the development of the system including the change management is not hampered.

6.2.3. The local vendor, who wishes to partner with foreign firms, must have adequate local staffs, as indicated under staffing requirement working with the staffs of the foreign firms, so that there is better transfer of experiences, knowledge & technology. This is done, so as to enhance the capacity & competitiveness of the local firms, who can confidently undertake similar projects in the future without partnerships.

6.2.4. Presence of local staff as key members in the project team is necessary conditions to accept the proposal for evaluation.

6.2.5. The vendor awarded the contract shall not subcontract the awarded work partly or in full to any National/International Firms. This clause nullifies all the clauses pertaining to subcontracting that contradict this one, in any part of the document.

6.3. Patent and Copyright

6.3.1. The Vendor represents that the Solution or any product/component, supplied by the Vendor does not infringe any patents and copyright. If, however, a third party claims that the Solution or any product/component thereunder, supplied by the Vendor under this Contract, infringes a patent or copyright (“IP Claim”), the Vendor will defend the Client against the IP Claim at the Vendor’s expense and pay all costs, damages and legal fees that a court finally awards.

6.3.2. If the Vendor determines that no alternative is reasonably available, and the Client agrees to return the Product/Component/Solution to the Vendor on the Vendor’s written request, an appropriate compensation has to be proposed and be acceptable to the client.

6.3.3. The Vendor has and will have no obligation to the Client regarding any “IP Claim” based on:

6.3.3.1. The Client’s modification of a Product/Component under the Solution unilaterally ;

6.3.3.2. use of the program in other than its specified operating environment;

6.3.3.3. the combination, operation or use of a product/component under the Solution with any other product, program, data or apparatus, not furnished by the Vendor, provided that the use of such product, program, data or apparatus has not been envisaged in this Contract and such product, program, data or apparatus is solely responsible for such infringemen t.

6.4. Quality of Work The Vendor must ensure quality while implementing the system at all times. This will be evaluated by the DITT in long run and this will have bearing on awarding similar Government Projects that are in pipeline and also those projects that will be taken by the Government in the future.

6.5. Timely Completion The entire work of software development and testing should be completed within 9

months from the date of receipt of letter of award of work. The time period of 9 months is for the vendor is only for collecting requirements, designing, development and testing of the software. Training of Master Trainers may be conducted only after testing and acceptance of the software by the DITT. The training should not take more than one month. The list of project deliverables is indicated in Annexure V.

6.6. Confidentiality of offe r The details of the offer proposed by the Vendor or its acceptance thereof with or without modifications by DITT shall not be passed in part or full to any third party without prior written approval of the parties involved. This applies to both client as well as the vendor.

6.7. Time Frame for completion

The software package for the work described in PART V should be developed, tested and submitted for final implementation within 9 months. The vendor should submit their plan for implementing the software at the premises of the Procuring Agency.

6.8. Implementation Arrangements The assignment shall be conducted in close consultation with the Department of Information

Technology and Telecommunications (DITT) who shall: 6.8.1. Arrange meetings with all relevant stakeholders. 6.8.2. Provide access to all documents and data necessary for the early

and successful completion of the assignment. 6.8.3. Provide space for training/workshop. 6.8.4. Provide a staging environment API credential for testing of system

integration (G2C) services with data-hub platform 6.8.5. Provide development room with internet facilities during onsite

development.

7. MINIMUM REQUIREMENTS FOR THE BIDDER

The bidder desirous of quoting for the work should satisfy the following minimum requirements:

7.1.1. The bidder should have the valid license for performing the consultancy service in the software development work in Bhutan.

7.1.2. The bidder should have adequate technical manpower to carry out

the project and complete it on time. All the professionals should be employed on full time basis and their responsibilities delegated based on the standard software development team

7.1.3. The bidder can collaborate and partner with foreign firms, but

presence of local manpower is necessary to build capability and competitiveness of the local firms to provide Maintenance support to the system as and when required.

7.1.4. There must be at least 1 full time National Project Manager with

sound technical knowledge of IT Project Management, 1 National / International Senior System Analysts with sound knowledge of System and Database Architecture and Design and 2 National / International Senior Developers having worked on projects involving web-service technologies such as Oauth2, REST, SOAP and SSO. DITT/Procuring Agency will monitor and verify them through CV and in person. Attach certificates of relevant certification like project manager with Project Management certification, developer with Java certification etc.

7.1.5. In addition to clause 4 above, the firm must have minimum of 4

Bhutanese Developers who are employed on a full time basis. The client (DITT/Procuring Agency) will verify and monitor them through their CV and in person as necessary.

7.1.6. The Project Manager, System Analysts, Developers or any other

technical member of the team must be involved in the project full time and shouldn’t leave until the product is accepted by the client, unless under unavoidable circumstances whereby permission to replace a particular resource may be sought in written form, from the client (DITT) on a condition that there would not be a major impact on the project. Thus, it is advisable for the bidder to have a bond signed with the personnel involved in the project at least for the period of the execution of the project and ensure proper transfer of knowledge to its local team to handle critical bugs and change request during the warranty and AMC period.

7.1.7. The bidder must submit the original CV with photograph for all the

team members for this project. This will be later verified by the client during evaluation as well as during the execution of the project.

7.1.8. The bidder must comply with the minimum requirements for the Software Development Laboratory as below:

7.1.8.1. There should be at least one server for the design and development of the software.

7.1.8.2. The lab should have around 10 client machines with genuine operating system and necessary application software installed.

7.1.8.3. The lab must be properly networked with Internet facilities. 7.1.8.4. The environment of the lab should be very conducive for the

project team to work, discuss and solve problems. 7.1.8.5. The vendor should also provide 2-3 machines for DITT team,

so that they can be fully involved in the development processes.

7.2. Staffing Requirement The Consultant should demonstrate the following advanced skill sets within its team as well as the indicative qualifications by individual and associated duration of each team member’s involvement in the project:

7.2.1. Project manager A competent project manager cum business analyst with a minimum qualification of bachelors. Should have experience worked as project manager in similar projects and well versed with software development methodologies, preferably SCRUM framework.

7.2.2. Sr . Developer Minimum of 2 Sr.developers with a qualification of Bachelors in IT field with java language development experiences. Having a certification in Java from any renowned partners will be considered

as added advantage. Must have worked in projects that has component on system integration, web services technologies such as REST, SOAP, Oauth2 and single sign on (SSO) features.

7.2.3. System engineer At least one system engineer with a minimum qualification of Bachelors in IT field with experience in integration of system. Should have experience in Linux OS based servers and should have worked with NGINX servers and HTTP caching tools. It will be an added advantage if the system administrator is well versed with development and operation configuration best practice such as DevOps.

.

8. ANNEXURE

Annexure I - List of services/systems to be migrated to datahub platform

S/N

System/Service Details To integrate with SSO

Agency

Type Agency Service Name

Service

Description Operations

Access Point Payment

Method Open/H

ome CC Dz/R HQ

1 MoHCA DCRC Birth Registration Register new

births

Functional

1 1 Offline

2 MoHCA DCRC First Time CID/ SRP

Card Issuance

Issue CID/SRP

Card printed for

the first time 1 1

3 MoHCA DCRC Replacement of CID/

SRP Card

Issue CID/SRP

Card printed for

the lost/damage

case

1 1

4 MoHCA DCRC Death Registration Update deaths 1 1

5 MoHCA DCRC Census Transfer

Transfer census

(Inter-Dzongkha

g,

Intra-Dzongkhag

, Intra-Gewog)

1 1

6 MoHCA DCRC Name/ DoB Change

Update any

change in

Names/ Date of

Birth

1 1

7 MoHCA DCRC Census Upgrade/

Downgrade

Update census

status of an

individual 1

8 MoHCA DCRC Natuaralization/

Regularization

Register an

individual if one

is granted

citizenship by

naturalization

or

regularization.

1

9 MoHCA DCRC Household

Information

Issue certificate

showing the

total number of

active members

in one

household

1 1 1

10 MoHCA DCRC Citizen Individual Info

Request

Issue certificate

showing the

information of

an individual

1

11 MoHCA DCRC Issuance of

Nationality Document

for Minors

Issue certificate

showing the

individual

information for

minors (14 years

and below)

1 1

12 MoHCA DCRC Change of Citizen

Information

Update/correct

an individual's

information 1 1

13 MoHCA DCRC Change of Spouse

Information Update spouse

information 1 1

14 MoHCA DCRC Change of Head of

Household

Update head of

the household

for an

household

1 1

14 0 4 8 14

1 MoFA DoP Issuance of Passport

(New/ Renewal/

Replacement)

Issuance of four

types of

passports -

Diplomatic,

Official,

Ordinary and

Travel

document.

Functional 1 1 1 1 1. Online

2. Offline

at DOP

1 1 1 1 1

1 AA RCJ Marriage Certificate

Applying

Marriage

Certificate

online or

Testing,

Piloting in

Thimphu

1

walking in to

office directly

2 AA RCJ Name Change Authentication

of Name 1

3 AA RCJ Translation of

Marriage Certificate

Translation of

Marriage

Certificate 1

4 AA RCJ Lost Documents 1

5 AA RCJ Single Status/

Marriage Status 1

6 AA RCJ Attestation of

Documents 1

7 AA RCJ Child Adoption 1

8 AA RCJ Organ Transplant 1

9 AA RCJ Closing of Accounts &

Transfer of Shares 1

10 AA RCJ Attest Agreement,

wills, contracts and

testaments 1

11 AA RCJ Child Travel

Documents 1

11 11

1 AA BCSEA Issuance of duplicate

examination

documents

Issuance of

duplicate

examinations

documents for

class X and XII,

year 2006 and

above. (For the

year 2001 to

2005 candidates

can availe

offline services,

since the data

are in different

format we could

not migrate in

G2C system)

Functional

Open

Docum

ents

collecti

on

from

Office

1. Online,

2. Offline

at BCSEA

2 AA BCSEA Issuance of

Replacement

documents

Issuance of

duplicate

examinations

documents for

class X and XII,

year 2006. (For

the year 2001 to

2005 candidates

can availe

offline services,

since the data

are in different

formate we

could not

migrate in G2C

system)

Open

Docum

ents

collecti

on

from

Office

1. Online,

2. Offline

at BCSEA

3 AA BCSEA Issuance of English

Language Proficiency

Certificate

Issuance of

English

Lanaguage

Proficiency

Certificate

(ELPC). (For the

year 2001 to

2005 candidates

can availe

offline services,

since the data

are in different

formate we

could not

migrate in G2C

system)

Open

Certific

ate

collecti

on

from

Office

1. Online,

2. Offline

at Bcsea

4 AA BCSEA View Class X & XII

Examination Results Can view results Open free

5 AA BCSEA Clerical Recheck of

Papers

Only after

declaration of

results.

Announcment

will be made in

media and

official website

to avail this

services

1. Online,

2. Offline

at BCSEA

6 AA BCSEA BCSEA Service Charge

Calculator

Service charge

calculator is a

component for

client to check

charges for the

above services.

If they are not

aware of

charges clients

can use this

component

6

1 MoE DAHE Application for (UG)

scholarships

Students apply

for UG

scholarship.

Verification of

applicants by

the verifier.

Tracking of

Application

status

Generation on

Merit Ranking

Allocation of

Scholarship to

the students

Functional

Open Offline

2 MoE DAHE DAHE Scholarship

Student's Joining

Report

UG scholarship

student get

registered

providing their

abroad contact

address and

other necessary

information

after joining the

college

Open Offline

3 MoE DAHE Scholarship and BSA

Payment Process

Generation of

Release

Instruction

Updation of

payment status

Agency Offline

MoE DAHE

Application for

Student Studying

Outside Bhutan and

BSA Registration

Registration of

tertiary

students

studying abroad

and forming a

Bhutanese

Student

Association.

President and

Vice President

propose for

fund.

Verification is

done by BSA

dealing officer

in DAHE. BSA

fund is provided

as per the

number of

students

registred online

as BSA member

Open Offline

MoE DAHE Application for new

BSA

Verification of

new local

chapter

application by

BSA President

and dealing

officer

Open Offline

4 MoE DAHE Application for

student loan for

tertiary education

Students apply

for student

loan.

Verification of

applicants is

done by

Officials in

Higher

Education

Planning

Division.

Generation on

Merit Ranking

Updation of

payment made

to the students

Open Offline

6

1 AA DRA Registration of

Competent Person Development

completed,

2 AA DRA Application for

Technical

Authorization

Testing

inhouse

3 AA DRA Import Authorization

3

1 MOEA DCSI Application for

Cottage and Small

Scale Industry License

Approval and

issuance of new

industries

licensesApprova

l and issuance of

new industries

licensess

Functional

-Completed

open

2 MOEA DCSI

Application for

Renewal of Cottage

and Small Industry

License

Renewal of

industries

licenses

annually

open

3 MOEA DCSI

Application for

Duplicate Cottage &

Small Scale Industry

License

Issuance of

duplicate

license in case

of lost/damaged

open

4 MOEA DCSI

Application for

Cancellation of

Cottage - & Small

Scale Industry License

Formally

cancellation of

industry license

by license

open

5 MOEA DCSI

Application for

Change of Cottage &

Small Scale Industry

License -5.1

Ownership transfer in

licenses

Transfer of

license

ownership open

Six

Regi

onal

Trad

e

and

Indu

stry

Offi

ces

6 MOEA DCSI

Application for

Change of Cottage &

Small Scale Industry

License -5.2

Establishment name

change

Change of

license

establishment

name

open

7 MOEA DCSI

Application for

Change of Cottage &

Small Scale Industry

License -5.3 Location

change

Location change

from existing to

new location open

8 MOEA DCSI

Application for

Change of Cottage &

Small Scale Industry

License -5.4

Upgradation/Down

gradation of scale of

business

Up gradation of

existing license

from cottage

scale to small

scale due to

increase in

capital

investmenr

scale and doen

gradation of

license if actual

total capital

investment of

establishment is

within cottage

scale

open

8

1 MoEA DoT Micro Trade

Registration

Certificate

Functional

open

2 MoEA DoT Renewal of Micro

Trade Registration

Certificate open

3 MoEA DoT

Issuance of Duplicate

Micro Trade

Registration

Certificate

open

4 MoEA DoT Issuance of Wholesale

Trade License open

5 MoEA DoT Renewal of Wholesale

Trade License open

6 MoEA DoT Cancellation of

Wholesale Trade

License open

7 MoEA DoT Issuance of Duplicate

Wholesale Trade

license open

8 MoEA DoT Retail Trade License

Issue open

9 MoEA DoT Retail Trade License

Renewal open

10 MoEA DoT Cancellation of Retail

Trade License open

11 MoEA DoT Issuance of Duplicate

Retail Trade License open

12 MoEA DoT Ownership Transfer in

license open

13 MoEA DoT Establish Name

Change open

14 MoEA DoT Location Change open

15 MoEA DoT Upgradation and

down gradation of

scale of business open

16 MoEA DoT Import House

Registration open

17 MoEA DoT Issuance of Import

License open

17

1 MoEA DoI FDI Project

Registration and Final

Approval

Functional

open

2 MoEA DoI Domestic Project

Approval open

3 MoEA DoI Issuance of Industry

License open

4 MoEA DoI Renewal of Industry

License open

5 MoEA DoI Cancellation of

Industry License open

6 MoEA DoI Change of Industry

License open

7 MoEA DoI Issuance of Duplicate

Industry License open

8 MoEA DoI Application for

Environment

Clearance open

9 MoEA DoI Renewal of

Environment

Clearance open

9

1 MoLHR DEHR Online registration of

job seeker and posting

profiles

Functional

open

2 MoLHR DEHR Job Search and Apply

for Jobs (Job seekers) open

3 MoLHR DEHR Online registration of

employers open

4 MoLHR DEHR Job Posting by

Employers open

5 MoLHR DEHR Online shortlisting of

potential employees

by employers open

6 MoLHR DEHR Management of

National Employee by

employer open

7 MoLHR DEHR Job Approval by

Employment Officer open

8 MoLHR DEHR Management of

trainings open

8

1 MoLHR DoL Issuance of Fresh

Approval for Foreign

Workers Recruitment

Functional

2 MoLHR DoL Issuance of Additional

Approval for Foreign

Workers

3 MoLHR DoL

Approval of

Foreign Worker

Recruitment

agent and

labour officer

4 MoLHR DoL Resubmission of

Application

5 MoLHR DoL

Forewarding of

Application for

LRC (Labour

Recruitment

committee)

6 MoLHR DoL Renewal of Work

Permit for Foreign

Workers

3

1 MoAF DoL

Input Supply of Feed

& Fodder Dev completed,

Minor change

request

2 MoAF Input Supply of Live

Animals

3 MoAF NCAH Animal Health

3

1 MoAF DoFPS Rural Timber Permit Functional

1

2 MoAF DoFPS Permit for Flag pole,

Fencing pole and

Firewood 1

3 MoAF DoFPS Non-wood Forest

Product Permit

Not in Use

4 MoAF DoFPS Permit for Removal of

Forest Products from

Private Land

4

1 AA CDB Registration of new

contractor

Developing

(95%)

Due to

complete

(31/08/17)

2 AA CDB Renewal of CDB

Certificate

3 AA CDB Up-gradation of

contract license

4 AA CDB Name, ownership and

location change of

contractors

5 AA CDB Registration of

architects

6 AA CDB Renewal of Architect

7 AA CDB Issuance of Duplicate

CDB certificate

8 AA CDB Cancellation of CDB

Certificate

9 AA CDB Registration of

consultant

10 AA CDB Addition of category

for consultant

11 AA CDB Registration of

specialized trade

12 AA CDB Addition of category

for contractors

12

1 MoWH

S DES eBSR Development

Completed,

Testing

- - - 1

2 MoWH

S DES Building Approval

System - - - 1

2 2

1 AA NHDCL

Online submission and

selection of Housing

Allotment

applications

Development &

Testing

Completed,

Issue with

Major Change

Request after

Change in

Management

2 AA NHDCL

Online submission and

processing of housing

maintenance

applications

3 AA NHDCL Management of

monthly rental

remittance

3

1 AA TT Building Construction

Completed

2 AA TT Issuance of Building

Occupancy certificate

3 AA TT New water line

connection

4 AA TT Water pipeline

shifting

5 AA TT Water pipeline main

shifting

6 AA TT Disconnection and

reconnection of water

7 AA TT Replacement of water

meter

8 AA TT Upgradation /

downsizing of water

connection capacity

9 AA TT Sewer connection to

main sewer line

10 AA TT Vacuum tanker

services

10

1 AA PT Building Construction

Completed

2 AA PT Issuance of Building

Occupancy certificate

3 AA PT New water line

connection

4 AA PT Water pipeline

shifting

5 AA PT Water pipeline main

shifting

6 AA PT Disconnection and

reconnection of water

7 AA PT Replacement/Shifting

of water meter

8 AA PT Upgradation /

downsizing of water

connection capacity

9 AA PT Sewer connection to

main sewer line

10 AA PT Vacuum tanker

services

Direct/online

Grievance

10

1 AA GT Building Construction

Testing

completed

2 AA GT Issuance of Building

Occupancy certificate

3 AA GT New water line

connection

4 AA GT Water pipeline

shifting

5 AA GT Water pipeline main

shifting

6 AA GT Disconnection and

reconnection of water

7 AA GT Replacement of water

meter

8 AA GT Upgradation /

downsizing of water

connection capacity

9 AA GT Sewer connection to

main sewer line

10 AA GT Vacuum tanker

services

10

1 AA ST Building Construction

Functional

2 AA ST Issuance of Building

Occupancy certificate

3 AA ST New water line

connection

4 AA ST Water pipeline

shifting

5 AA ST Water pipeline main

shifting

6 AA ST Disconnection and

reconnection of water

7 AA ST Replacement of water

meter

8 AA ST Upgradation /

downsizing of water

connection capacity

9 AA ST Sewer connection to

main sewer line

10 AA ST Vacuum tanker

services

10

1 AA RAA Audit Clearance Functional

1

1 AA RBP Security Clearance Functional

1

Total eServices 152

1

AA

Commo

n G2C

System

s,

PSGRD,

CS

eKaasel

Portal where citizens can raise G2C or Non-G2C related grievances/ complaints/ feedbacks/ suggestions and track the status of their grievances

2 PM eDesk

monitoring dashboard for reporting statistics regarding G2C application summary, auto-escalation, revenue earned, CC login irregularities and total

application counts from various RGoB line agencies

3 SMS Gateway

SMS (ACK,

STATUS,

BROADCAST)

services for G2C

services

4 Citizen Portal

one-stop online access for G2C services catering both informational and transactional services

5 Portal User

Management

create and

manage

role-based login

credentials for

every different

portal users

Total Services 5

Annexure III - Change Request Contract (CRC)

i. If there is a major change(s) in the requirements of the system, the vendor must provide post implementation support under a Change Request Contract for [insert number of years] from the date of acceptance of the software package by DITT

ii. Change Request Charge will be estimated in terms of the man-day rate. In the financial

proposal, the vendor must submit the man-day rate for each person who will be involved in the change management. The rates should be valid for 1 year . The total cost for the change will be worked out from the quoted rates and the total man days needed to address the changes.

iii. The man-day rate payable to the vendor, as quoted for the first year, shall subject to

adjustment for the 2 nd and 3 rd year, taking in consideration of the local inflation. The adjustment will be made in accordance to the procurement manual of the Government in relation to the software engineering works.

iv. The format for quoting man-day rates is provided in the Annexure VI.

v. The Change Request is completely need based and payments are made only based on the major changes agreed between the parties.

vi. The vendor must use all reasonable efforts to study the requirements of the system

thoroughly during the initial implementation period.

vii. The vendor shall not entertain frequent changes in the system from the client, once the requirements are finalized, which will adversely affect the project completion date and delay the project. However, the changes that come through the change management shall be executed by the vendor under the terms and conditions of Change Request Contract (CRC).

viii. Whenever there are major new requirements due to change in the

procedures/guidelines of the DITT, the client will ask for additional requirements through a Change Request Document. The work involved in the change request and the cost will be worked out by both clients and vendor and a cost will be agreed within the framework of the Change Request Contract (CRC).

ix.The CRC will be initiated, if the change is considered major, bringing in a major impact on the database or adds more input screens.

x. The minor modifications of fields within an existing screen or changes having minor or

no impact on the database will be handled as specified in the Warranty Support. The minor changes will not be handled by Change Management Contract.

xi. The CRC will also be initiated, if the Client decides to introduce any new technologies in

replacement of the Solution or along with the Solution, due to advancement of the technologies, as may deem necessary for the system by the vendor. Such CRC will occur, provided that the above work scope is not being covered under the license agreement.

xii. The SDV will be in binding to carry out the Change Request Request made by the

client for 3 years after the acceptance of the system by the DITT. An agreement will be signed for this contract.

Annexure IV - ToR for Training of master trainer

i. The master trainers refer to all those system users including System

Administrator, Data Administrator, Network Administrator, Managers and other end users specified by the client. The list of Master Trainers will be provided by the client one week before the trainings begins.

ii. The vendor must provide a sufficiently detailed training plan before the start of training to DITT. The plan should contain an indicative list of resources that would be allocated from the vendor’s side.

iii. The vendor shall provide the necessary infrastructure for the training at a suitable location in Thimphu.

iv. The DITT shall be responsible for identifying the trainees. v. The training will be conducted for 10-15 days as required and

decided by DITT in consultation with vendor. The training should not take more than 1 month.

vi. The trainees must be provided with training materials/manuals that would cover all the facets of the software and installation. The trainees must also be provided with other training aids and tools, which would help them to receive proper trainings and better understand the system modules and usage.

vii. The vendor will provide adequate training to the System Administrators, Data Administrators or Managers from DITT on system deployment & operation, server and system configuration and installation, backup services, Directory Management, security requirements, and other necessary technical services, which will enable them to use the system for timely and accurate production of required information within their area of authority and responsibility.

viii. The deployment of two/three developers from for the project will also be part of training of master trainers. The SDV must actively involve them in all the phases of system development, so that there will be better transfer of technology and build in-house capacity to manage small corrections at later stage.

ix. On completion of the training, the master trainers and Users will be performing a rigorous test on the system and submit their observation(s). The observations will cover the following topics:

Comments on User Interface and suggestions for betterment;

Comments on operational flow; Response time of the system; Bugs encountered and error management facilities; Data validation and security measures; and

Documentations

x. The DITT would review the above feedbacks and direct the vendor to take necessary corrections or remedies. Based on the observations/comments made by the training participants, should the DITT feel that the training is not satisfactory or not adequately covered, then the vendor is liable for providing additional trainings.

Annexure V: Checklist of Project Deliverables

1. Software Requirement Specification Document (High level SRS and Low level SRS)

2. Software Design Document (SDD) 3. Working and Tested Software with source code 4. Migrated systems deployed at GDC with appropriate server/nodes architecture (As

described in under scope of work) 5. User and Administrator Manuals for the system including Online Help 6. Setup and Release notes for each new release 7. Test Cases and Reports 8. All database scripts 9. Training of trainers 10. Any other relevant documents, supporting software, etc mentioned above.

Annexure VI: Man-Day Rates for the Change Management for the 1 st Year

Sl.No. Personnel involved in the Project Rate per Man-Day (in Nu.)

Note: The Amount quoted should be inclusive of all taxes/duties. The rates for second and third

years will be negotiated later, taking the first year rate as the baseline.

Annexure VII – NON DISCLOSURE AGREEMENT

This agreement is entered into this ___ day of _______________________, 20__ by and between ______________________ (hereinafter "Recipient"), with offices at _____________________, and ______________________, with offices at _____________________ (hereinafter "Disclosure").

WHEREAS Disclosure possesses certain ideas and information relating to

__________________ that is confidential and proprietary to the Disclosure (hereinafter

"Confidential Information"); and WHEREAS the Recipient is willing to receive disclosure of the

Confidential Information pursuant to the terms of this agreement for the purpose of

_______________________; NOW THEREFORE, in consideration for the mutual

undertakings of the Discloser and the Recipient under this agreement, the parties agree to the

below terms as follows:

1. Disclosure . The Discloser agrees to disclose, and the Receiver agrees to receive the Confidential Information. 2. Confidentiality.

2.1 No Use. The Recipient agrees not to use the Confidential Information in any way or manufacture or test any product embodying Confidential Information, except for the purpose authorized by the Discloser.

2.2 No Disclosure. The Recipient agrees to use its best efforts to prevent and protect the Confidential Information, or any part thereof, from disclosure to any person other than the Recipient's employees that have a need for disclosure in connection with the Recipient's authorized use of the Confidential Information.

2.3 Protection of Secrecy. The Recipient agrees to take all steps reasonably necessary to protect the secrecy of the Confidential Information and to prevent the Confidential Information from falling into the public domain or into the possession of unauthorized persons.

3. Limits on Confidential Information . Confidential Information shall not be deemed proprietary, and the Recipient shall have no obligation with respect to such information where the information:

(a) Was known to the Recipient prior to receiving any of the Confidential Information from the Discloser;

(b) Has become publicly known through no wrongful act of the Recipient;

(c) Was received by the Recipient without breach of this agreement from a third party without restriction as to the use and disclosure of the information;

(d) Was independently developed by the Recipient without use of the Confidential Information; or

(e) Was ordered to be publicly released by the requirement of a government agency. 4. Ownership of Confidential Information . The Recipient agrees that all Confidential Information shall remain the property of Discloser and that the Discloser may use such Confidential Information for any purpose without obligation to Recipient. Nothing contained herein shall be construed as granting or implying to the Recipient any transfer of rights, any patents, or any other intellectual property pertaining to the Confidential Information. 5. Term and Termination . The obligations of this agreement shall be continuing until the Confidential Information disclosed to the Recipient is no longer confidential. 6. Survival of Rights and Obligations. This agreement shall be binding upon, inure to the benefit of, and be enforceable by (a) the Discloser, its successors and assignees; and (b) the Recipient, its successors and assignees. IN WITNESS WHEREOF, the parties have executed this agreement effective as of the date first written above. Discloser (Name of the Discloser ) Recipient (Name of the Recipient) Signed . Signed . Print Name . Print Name . Title . Title .

Date . Date .

Annexure VIII : SSO and API Invocation flow (language independent)

SSO and API Invocation flow (language independent)

To integrate client applications with the Datahub platform, we need an unique client id and secret for each and every application. Development team suppose to provide login redirect url and logout redirect url (if it has separate urls for login and logout) to DITT Datahub Team and make a request to register the client application in datahub side. [ https://tools.ietf.org/html/rfc6749#section­3.1.2.2 ] [ https://tools.ietf.org/html/rfc6749#section­10.6 ] Once DITT Datahub team provided the Client ID and Client secret, developers can start integrating the application with sso platform. Please refer the OIDC SSO Flow diagram section below NOTE: You can try the sample playground app [ https://docs.wso2.com/display/IS530/OAuth+2.0+with+WSO2+Playground ] to get some idea about how the SSO and access token generation happens.

Integrating SSO

Login Request(authorize request)

[ https://tools.ietf.org/html/rfc6749#section­4.1 ] [https://tools.ietf.org/html/rfc6749#section­4.1.1 ]

Staging URL https://stg­sso.dit.gov.bt/oauth2/authorize

Production URL https://sso.dit.gov.bt/oauth2/authorize

Once the client application detects that the user is not authorized, it should initiate the authorize request to login with Datahub identity platform.

query parameters response_type=code&client_id=<client_id>&scope=PRODUCTION&redirect_uri=<application_callback_url>

headers application/x­www­form­urlencoded

Application_callback_url : URl which get redirected to after login with the code value Redirected url will look like bellow [ https://tools.ietf.org/html/rfc6749#section­4.1.2 ]

© 2010 WSO2

Sample callback with parameters

http://xxx.xxx.xxx.xxx:xxxx/ViewCitizenDetails/sso/acs?code=20258599­d436­30ae­bf7b­c331fdca7cdf

&session_state=fe505a62a3d313db043670185ebde767e2956a96c5e7ba081974f8bdb678848c.Uq0tOhKc

3avTdKU2­­V2_w With the callback after successful login, Client application will receive a token as a request parameter called code. Client application is suppose to read the value of the code , session_state parameters and store in client session.

Generation access token for SSO users.

[ https://tools.ietf.org/html/rfc6749#section­4.1.3 ] NOTE: Following requests should be done in server side (using languages such as Java, php, csharp, nodejs, etc.) and never send the call from browser. To access the API, we need an access_token. We can use the authorization code, which we got at the time of login in in previous step, to generate an access token. Soon after client application receive the code, Application can make a token request and get an access token.

Endpoints

Staging URL https://stg­sso.dit.gov.bt/oauth2/token

Production URL https://sso.dit.gov.bt/oauth2/token

query parameters grant_type=authorization_code&code=<code retrieved by previous step> &redirect_uri=<application_callback_url>

headers application/x­www­form­urlencoded TODO issue with header in client code

POST /token HTTP/1.1

Host: server.example.com

Authorization: Basic

SVpzSWk2SERiQjVlOFZLZFpBblVpX2ZaM2Y4YTpHbTBiSjZvV1Y4ZkM1T1FMTGxDNmpzbEFDVzhh

Content‐Type:

© 2010 WSO2

application/x‐www‐form‐urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A

%2F%2Fclient%2Eexample%2Ecom%2Fcb

Expecting a response like follows [ https://tools.ietf.org/html/rfc6749#section­4.1.4 ] [tokenid spec TODO]

"access_token": "fad53b4a­24f0­3a52­add3­b4298379bcdb", "refresh_token": "e2e9a402­e9ea­3a52­864e­eaa73603233a", "scope": "openid", "id_token": "eyJ4NXQiOiJObUptT0dVeE16WmxZak0yWkRSaE5UWmxZVEExWXpkaFpUUmlPV0UwTldJMk0ySm1PVGMxWkEiLCJraWQiOiJkMGVjNTE0YTMyYjZmODhjMGFiZDEyYTI4NDA2OTliZGQzZGViYTlkIiwiYWxnIjoiUlMyNTYifQ.eyJhdF9oYXNoIjoiZkcyOEJKR0NpcndzZFVwSkhiaXlUUSIsInN1YiI6ImRwZXJlcmEiLCJhdWQiOlsiZlhnWDUybEVRb0lObXlOX1NVUFJVbjBMbUNnYSJdLCJhenAiOiJmWGdYNTJsRVFvSU5teU5fU1VQUlVuMExtQ2dhIiwiYXV0aF90aW1lIjoxNTE4MjQxNzg2LCJpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0Ojk0NDRcL29hdXRoMlwvdG9rZW4iLCJleHAiOjE1MTgyNDUzODcsImlhdCI6MTUxODI0MTc4N30.GN6gQKLxI3DqVLMR2U53JZHJ­12HCFSFcqXPZ2N0N­NQrXyHViKabWlPpBq32SGWsfxeRx­QqsLCrnyeiVmO7QkkW5tz8rpGx­nhfBulFSglM04v5wOnbJbVRNzGWWzHGFa71H8O4TwETb_LedJ_cGxPVyADWPnMn2QoazHeww4", "token_type": "Bearer", "expires_in": 3235

Information retrieving from above response need to saved in the user session. These information are unique for each user , hence naver save these information in application session.

access_token Token that client apps need to use for API Calls as a Bearer Authorization header.

refresh_token Token which we used to generate new access token when the current access token is expired.

id_token There will be three base64 encoded values in this section separated by dot (.). Second portion of the string will contain following data in JSON format. NOTE: You need to decode it first after splitting and parse the JSON

© 2010 WSO2

username http://wso2.org/claims/role (Roles associated with the user as ) firstName middleName lastName mobileNo http://wso2.org/claims/emailaddress (Email address of the user) authorizedCID [including children under the legal age(18)]

[ https://medium.com/@hasiniwitharana/openid­connect­532465308090 ] [ http://openid.net/specs/openid­connect­core­1_0.html#IDToken ]

Renewing the access token

Endpoints

Staging URL https://stg­sso.dit.gov.bt/oauth2/token

Production URL https://sso.dit.gov.bt/oauth2/token

query parameters grant_type=refresh_token&refresh_token=<refresh token>

headers Content­Type: application/x­www­form­urlencoded Authorization: Basic <Base64­encoded­client_key:client_secret>

For more details : https://docs.wso2.com/display/AM210/Refresh+Token+Grant

Check session

TODO : will update and send the final version

© 2010 WSO2

Implementing the Logout functionality

[ https://docs.wso2.com/display/IS540/OpenID+Connect+Logout+URL+Redirection ] Client application should use the following URL to logout the user from the SSO session. Once user clicks the URL, user will be redirected to the SSO portal and asking for logout confirmation. Once confirmed, user will be logout from the SSO portal side and redirect back to the application to handle the logout in the application side.

Endpoints

Staging URL https://stg­sso.dit.gov.bt/oidc/logout

Production URL https://sso.dit.gov.bt/oidc/logout

query parameters post_logout_redirect_uri=<logoutCallbackURL>&id_token_hint=<ID Token>

headers Content­Type: application/x­www­form­urlencoded Authorization: Basic <Base64­encoded­client_key:client_secret>

© 2010 WSO2

Generating token for internal users (Application to Application )

[ https://docs.wso2.com/display/AM210/Client+Credentials+Grant ] [ https://tools.ietf.org/html/rfc6749#section­4.4 ] We use client credential grant type to generate access tokens for internal users. The token we use in this case will be shared within the client application (All the internal users will be using the same access token at a any given time). This token need to be saved in the application session in client application.

Endpoints

Staging URL https://stg­sso.dit.gov.bt/oauth2/token

Production URL https://sso.dit.gov.bt/oauth2/token

query parameters grant_type=client_credentials

headers Content­Type: application/x­www­form­urlencoded Authorization: Basic <Base64­encoded­client_key:client_secret>

Access API Using Access token.

Use the correct access token to access the APIs which are subscribed to the token generated Application.

query parameters As required by the API

headers Accept: application/json Authorization: Bearer access_token

Endpoints

Staging URL https://stg­api.dit.gov.bt/ <api_context>/<api_version>/<apiresource>

Production URL

https://api.dit.gov.bt/ <api_context>/<api_version>/<apiresource>

© 2010 WSO2

* If you are using Swagger generate SDK client, the api resource will be wrapped by the sdk client and exposure as methods. Ex: of using JAVA SDK client

OkHttpClient client = new OkHttpClient(); client.setReadTimeout(15, TimeUnit.SECONDS); client.setConnectTimeout(15, TimeUnit.SECONDS);

ApiClient apiClient = new ApiClient(); apiClient.setHttpClient(client); apiClient.setBasePath("https://localhost:8245/nlcs_landdetailapi/1.0.0"); apiClient.setAccessToken("<access token>"); apiClient.setVerifyingSsl(false);

DefaultApi api = new DefaultApi(apiClient);

LandDetailResponse detailResponse =

api.landdetailsbycidCidGet("11705002040", null); List<LanddetailObj> landdetailObjs = detailResponse.getLandDetails().getLandDetail();

if (!landdetailObjs.isEmpty())

for (LanddetailObj landdetailObj : landdetailObjs) System.out.print("DzongkhagOrThromde :" +

landdetailObj.getDzongkhagOrThromde()); System.out.print(", GewogOrThromdeVillage :" +

landdetailObj.getGewogOrThromdeVillage()); System.out.print(", LandLocationFlag :" + landdetailObj.getLandLocationFlag()); System.out.print(", LandTypeOrPrecinct :" + landdetailObj.getLandTypeOrPrecinct()); System.out.print(", OwnerCid :" + landdetailObj.getOwnerCid()); System.out.print(", OwnerName :" + landdetailObj.getOwnerName()); System.out.print(", OwnershipType :" + landdetailObj.getOwnershipType()); System.out.print(", PlotAreaUnit :" + landdetailObj.getPlotAreaUnit()); System.out.print(", PlotId :" + landdetailObj.getPlotId()); System.out.print(", ThramNumber :" + landdetailObj.getThramNumber()); System.out.print(", PlotNetArea :" + landdetailObj.getPlotNetArea());

System.out.print(", LapNam :" + landdetailObj.getLapName()); System.out.print(", PlotNetArea :" + landdetailObj.getDemkhongName()); System.out.println(""); System.out.println("#####################################");

else System.out.println("No land detail Data"); System.out.println("#####################################");

© 2010 WSO2

OIDC SSO Flow diagram

© 2010 WSO2