After the first three weeks of our discovery, we reflected on what we’d learned about user management for Government as a Platform (GaaP) products. The alphas we’d considered were too influenced by the desire to try out a promising technology in this area, and they couldn’t be linked clearly to specific user needs.
Sometimes, at the end of discovery, you find the best thing to do is keep discovering. So we did.
Separating user need from technology
First, Will Myddelton the GaaP programme lead for user research, set us a challenge. Could we write our user needs without any reference to technology whatsoever?
This was hard. Really hard. But it made us rethink end-user needs and their business contexts. Matching a particular technology to a user need could be done later, but first and foremost we had to separate the need from the technology.
Redefining our user groups
We agreed to only look at the user needs for accessing services, not any of the business functionality beyond that. We defined 4 user groups:
- people who run services - Senior Responsible Officers, service managers or product owners
- people who build services - developers and technical architects
- people who use services - operational staff
- people who administer people for others - IT, HR, helpdesks
Some users will appear in more than one of these groups, depending on the context. For example, developers in the Digital Marketplace team need to control access to their software, so in that context they fall into the ‘people who build services’ user group. But when they act as consumers of GOV.UK Notify they're in the ‘people who use services’ group.
The last group was, in many ways the most interesting, and one that hadn’t been explored during the first discovery. We’ll come back to the others later.
User groups define the technology
Across government, some parts of user management for email and general desktop applications are largely industrialised. This is possible if you view ‘logging in’ as two different processes.
Authorisation
This is what a user is allowed to do within a service. A service will have its own policy on which features and functions a user has access to. Information on a user's office location, job role or security clearance are factors that may be used to decide what a user can access.
Each service makes that decision based on its own set of criteria. Given the complexity of that landscape, we’re not including authorisation in our scope at this stage.
Authentication
This is the process that tells a service that a user is who they say they are.
Departments already ask staff to log in to their computers each morning, and check staff’s identity with a username and password. But they can add extra reassurance with a second factor authentication, such as a smartcard or code sent by SMS. Once logged in, an account can be used as a single source to authenticate a wide variety of systems within departmental firewalls - sometimes without staff even knowing it's happening.
A single source of employee status for a department also gives them security benefits such as:
- fewer passwords to remember so staff are less likely to write them down, or reuse their personal passwords
- the ability to revoke access to the majority of services within minutes when staff leave
User management is different in the cloud
Many digital services aren’t built this way. They’re in the cloud with no access to departmental directories. This means they authenticate using their own lists of usernames and passwords, which staff have to remember. Alternative strategies are then used to improve security.
Short timeouts mean staff are less likely to leave a system exposed, but they give a poor user experience. To keep track of staff movements, service ‘superusers’ are created. These are people who have better on-the-ground knowledge, but this isn’t a perfect solution and costs more.
GaaP services follow these common patterns, so where there's a fairly small user base, service teams can manage both the authorisation and authentication processes. However, in the long run that won’t be sustainable.
By focussing on our fourth user group, we're able to use their wide-ranging needs to imagine a more sustainable plan.
Do we really want to create and grow a new support team that's distributed across government to manage a vast number of services, and is tied closely into every departmental leavers process? Or can we find a way to cross the firewalls and link to what already exists?
If we did that, staff could reuse their normal password for digital services, and service managers could rely on accounts being automatically revoked when someone left. Developers wouldn’t have to build and support password reset. And there would be one less account management process in government.
Calling Common Technology Services...
During our discovery we looked at the draft guidance for identity providers and identity federation produced by Common Technology Services (CTS).
The identity provision guidance describes how departments can create a single user store for their staff that allows them to log into cloud services using their normal password. For example, some of us are familiar with using a Google account to log in to Basecamp, Trello or Pivotal Tracker.
The guidance sets out the principles of how services can delegate the task of authenticating a user to a dedicated service called an identity provider (IdP). The guidance also explains how to implement an IdP service - giving example network and infrastructure configurations - as well as information on how to set up digital services to work with an existing IdP.
Importantly the guidance talks about federated identity and explains that there may be separate IdPs for government departments and agencies. This ensures user data is more up to date without the need for a central store to hold all the staff logins for government. It also allows departments to set security controls that suit the work people do.
However, any service that wants to authenticate users from across government will need a user-friendly mechanism for staff to be routed to the IdP that’s relevant to them, so they can log in.
A service also needs to agree API keys with each IdP it plans to use. With many technologies this is a manual process, but for a service authenticating across the whole of government, this is no small undertaking.
Given that GaaP has multiple products, this routing and key management could be a lot of duplicated work for developers. Thankfully a technology called an authentication broker means we’ll only have to do this once. It will bring together all the IdPs and standards into a single shared endpoint for GaaP service developers.
In this diagram we show how users of a cross-department service would be authenticated via the broker, from their respective IdPs. The admin interfaces of any GaaP products would use the same mechanism. As a result users effectively have one password for the whole service.
Many digital teams in government departments have Google Apps domains for their developers, which we could use. However GaaP products will need to be used by operational staff as well, so we need to be sure they can also authenticate once services go live.
We’ve also identified some government departments that already have identity providers for their entire staff, which may already be shareable. It's looking likely that although most departments will have these in place, it will take a few years.
This presents some challenges:
- we shouldn’t stop departments from using GaaP services just because their identity provider isn’t ready
- to minimise our security risk and admin overheads we’d prefer not to add large numbers of operational staff users to GaaP user stores
- waiting until departments are ready leaves end users with many logins in the meantime (migrating from one set of accounts to another is tricky and this gets harder as the number of users you have to migrate increases)
- we need to find a way to work with some organisations that don’t plan to implement an IdP for some time, but still need to use GaaP products now
Making it real for departments
Is there an alternative approach - one that allows GaaP and departments to use this new model but only having an impact on a small number of services?
Some possible scenarios are:
- for the pioneers, we could allow a limited number of accounts for each department. They’ll still be managed by GaaP, but we’ll encourage them to follow the CTS blueprints as they build their own service so they can investigate this new authentication model for themselves
- for services entering live operation with no departmental IdP, we can offer an interim solution so they can manage as their user numbers grow. This would allow them to start understanding the new support model needed for these identity services. Staff will still have to put up with a different login for cloud services, and the risks around imperfect processes for staff who are leaving, will remain
- for departments who have an IdP ready to authenticate all staff using the CTS patterns, we could integrate them now using live staff data while the number of dependant services is low
These scenarios give us the opportunity to prove the CTS patterns are ready for the:
- widespread adoption of cloud services
- greater cross-government collaboration
This diagram shows how we can use the shared authentication broker to support departments at different levels of maturity.
Our alpha will explore the feasibility of this approach and give us a clearer view of what the beta should be. It will also help us understand the user experience for staff users, highlighting where we need to do the hard work to make it simple.
To do this we’re going to extend our dummy service so that it authenticates against a prototype federated identity network. We’ll also modify GOV.UK Notify to work the same way.
We’ll take this to departments and talk to them about the practical challenges of operating such a system.
And we’ll revisit the four user groups we developed with Will Myddleton and explore:
- how will people who run services manage their users in a world of federated identity? How will they know they can trust it and that they can get support?
- how will people who build services need to change their approach if the user store is external? How will audit logs change? If a user moves to a new authentication provider (for technology or organisational reasons) what will the impact be?
- how will people who use services feel about creating accounts for (and authenticating into) internet-facing services with their normal password? How will we make this a consistent user journey for them?
- what’s the impact on staff who administer people for others? How ready are they? How will they start the journey to federated identity? What will they need to communicate internally? What will other teams such as IT, HR or an outsourced service desk need to know to support and work with federated identity?
Over the next few months we want to meet people working in all four roles, from a variety of departments. Perhaps the result of our alpha will be ‘wait, then migrate’, but if you’re looking at identity or ‘single sign on’ in your department or business team then we’d love to hear from you.
Follow Tom on Twitter and don't forget to sign up for email alerts.
GDS is expanding, and we have a number of positions that need to be filled - especially on the Government as a Platform team. So we’re always on the lookout for talented people. Have a look at our videos describing how we work, our vacancies page, or drop us a line.