Robert Gammon is the Technical Architect on the Early years qualification checking service, currently in the private beta stage of development.
Protecting a public service: how and why
When developing a new digital public service, you might wonder why it requires protection. Isn’t a public service meant to be open to everyone? Yes, but only after its official launch.
During the development phase, which may span several months, it's crucial to prevent search engines from indexing and restrict public access. This is especially important if it involves complex government policies that need to be correct and complete before going live.
Multiple versions of the service might exist. Such as development or test versions with unapproved features. We don’t want these non-public versions accessed by someone outside the team.
Our solution
Our team at the Department for Education (DfE) came up with a simple, user-friendly solution that is easily removed when the service is ready for public access.
- Our solution was driven by these key requirements:
- Access should be restricted to invited users only
- Unauthorised users should meet a polite, non-intrusive access barrier
- The solution must be straightforward for the team to maintain
- The solution must allow us to disable password protection entirely for the public-facing service
- The team should have confidence that any changes are tested in an environment mirroring the public service exactly
This focus ensured a secure, user-friendly, and future-proofed implementation.
We implemented a simple guard page that asks for a password. If the correct password is entered, the user can access the service. Otherwise, they are redirected back to the guard page. This setup allows different passwords for different environments and includes an 'on-off' switch to disable the guard page in production.
When we sent invitations to Early Years managers who volunteered to take part in the service’s pilot phase, we included the service address and a password, with a request not to share it. This approach has been successful and easy to manage. When the pilot ended, we simply changed the password to revoke access.
Other options considered
1. Formal login
We considered requiring users to create an account, which would allow us to verify who was accessing the service. However, we dismissed this possibility because:
- It would be inconvenient for users
- It could give a misleading impression that logging in is going to be required by the public service
- It would be costly to implement and maintain
2. IP address allow-list
We also considered restricting access to certain computers based on IP addresses. However, we dismissed this possibility because:
- It would be challenging for non-technical users who may not know how to find or share their IP addresses
- It’s an unreliable method since IP addresses change frequently
- We don't really want to filter on a user’s IP address anyway: what we need to know is that they have been invited to access the service
Conclusion
Instead of using complex solutions that are costly or hard to configure, like user management systems, or only allowing users to access the service from specific computers, we focused on our specific requirements and found a simpler, more user-friendly solution.
Leave a comment