Skip to main content

Opening the GOV.UK Verify Hub source code

The GOV.UK Verify team has evolved its approach to coding in the open over the last 5 years. The code within GOV.UK Verify started as a private project because it preceded the coding in the open policy.

We started our journey to opening up the GOV.UK Verify source code in 2016. We had to plan the order to open code so we were able to deliver continuous value.

GOV.UK Verify consists of several microservices and many libraries that are shared between them. We only opened applications when all the supporting libraries were available.  We opened the core hub libraries and applications as part of core mission work and opened test services during a firebreak.

Opening up GOV.UK Verify’s code

We opened up GOV.UK Verify code between August 2017 and April 2018 after carrying out full source code reviews for the core GOV.UK Verify Hub service and testing services. The GOV.UK Verify code is available in GDS’s alphagov repository.

The GOV.UK Verify components we opened up are:

  • the GOV.UK Verify Hub core microservices
  • the Verify Matching Service Adapter that is used by connecting government services to match users against their records (some work is underway to make matching users during the Verify journey optional)
  • a GOV.UK Verify Test Relying Party that is used to test the Verify Hub by showing all the ways a government service can interact with it (this application should not be used in production)
  • the GOV.UK Verify Stub IDP that pretends to be an Identity Provider in non-production environments
  • supporting libraries for all of these microservices

More details about the specifics of the repositories are available in the GOV.UK Verify technical documentation.

Keeping our code secure when open sourcing

Security was our highest priority when opening GOV.UK Verify code.

The GOV.UK Verify team had to:

  • guarantee secret data such as keys and credentials were not leaked
  • decide how to manage vulnerability patching and make sure code integrity was not compromised
  • decide whether to keep a commit history or flatten the history

The GOV.UK Verify team carried out a code cleanup on the repositories to remove information that identified real identity providers or government services integrated with GOV.UK Verify.

The GDS Cyber Security Team also reviewed code in the repositories to identify any patterns or sensitive information.  

The Cyber Security team used an automated tool called GitRob to check if any potential private data was present and remove it.

We had 20 repositories consisting of libraries and applications. As there was a lot of code to open, and limited capacity to review over 5 years of full history, we decided to only open the current version of the code. We’ve agreed to commit all future development work to newly-opened repositories.

We would have liked to have opened up the full history but we decided against this. We concluded that opening the latest code and using this as the canonical source would deliver more value than reviewing and cleaning up 5 years of commit history.

Overall we found it was difficult to open up our closed code. Our main challenges included:

  • coping with the sheer volume of code and history
  • getting code through the various reviews and sign offs
  • scheduling the opening of code against other work in a fast-moving environment

From our experience of opening the code it’s definitely easier to code in the open than to open a closed repository. Having open code enforces delineation between code and configuration and can make the code more reusable.

Benefits of open sourcing GOV.UK Verify

Our team gained all the expected benefits of coding in the open and we have been able to make use of free SaaS tools like:

  • Travis CI to test changes
  • Codacy to suggest code improvements

Open by default

Wherever possible any new GOV.UK Verify code is open by default. This includes the:

We still have some private GOV.UK Verify components. For example, we do not have any plans to open the Document Checking Service for a couple of reasons.

However, we have already seen the benefits of opening code and will continue to work in the open wherever possible. Let us know if you have any questions or comments below.

To make sure you stay up to date with all the latest developments, you can sign up to alerts from the Technology in government blog.

Sharing and comments

Share this page