Authenticating and Authorising is complex. Make it simple.

[lenniebriscoe]

Create A Challenge

Title

Authentication and Authorisation is complex to understand and get right. GDS should be looking to create a framework on top of OAuth2 and OpenIDC which other departments can benefit from.

Category

• [x] Data
• [ ] Document
• [x] Technical
• [ ] Other Suggestions

Challenge Owner

An IT Software Consultant currently working in an agency of the UK government.

Short Description

The agency has a number of individual applications. Each application has it's own implementation of Authentication and Authorisation. Each application has its own user database. Some applications only allow access to internal users of the organisation and others other allow both internal and external users. Generally there is an inconsistent approach. The inconsistency means a larger attack surface area. It means that developers that don't have experience in the complexities and often bake their own implementation of OAuth2.0 authentication into their application. Use of a framework such as the OpenSource IdentityServer4, or a GDS equivalent would bring conformity.

User Need

The agency would benefit through reduced development time of new applications, better security, potentially a single database of users, easier to grow services in the future. Developers working for the agency\Government Organisation wouldn't need to understand the nuances of application security and make simple mistakes with huge implications, implementation would be quicker and more secure. End users of agency applications would have better protection of their information through a consistent approach.

Expected Benefits

See User Need

Functional Needs

The choosing of technologies to adopt Authentication is fine but the following need to be addressed:

1. The Agency (I work for) wants a consistent approach to Authentication and Authorisation across all of its applications
2. Recognition that each 'client' that needs authentication and authorisation can be one of a number of technologies; javascript SPA application, MVC application, WebApi application, other native applications etc
3. Addition of additional clients shouldn't be a burden on the Authentication and Authorisation framework, i.e. its configuration should be data driven and potentially controlled by a simple management tool. Developers should be able to drop in simple packages into their app and apply common patterns to benefit from Authentication and Authorisation
4. Authentication and Authorisation should be solved together but kept separate. I have often seen an amalgamation of Authentication and Authorisation which muddies what both are trying to do violating Single Responsibility Principals. Everyone needs to be clear what each means and where the application responsibilities are.
5. Given that data security breaches are at an all time high, security should be at the top of every ones agenda. It isn't because 'business need' casually passes over security in favor of business functionality that provides Return On Investment. The best way to mitigate this is to create a framework that can be implemented, customized and provides a consistent extensible basis.
6. It doesn't need to be a one size fits all approach, but it does need to guide adopters on the right data security path. I have just reviewed 3 different applications here, each does Authentication and Authorisation differently. Consistency is key for maintainability.
7. Authentication and hence Identity is evolving. The chosen solution should evolve with it. Other 'things' that require consideration:
   • the Government Gateway is already doing some form of the common Authentication\Authorisation.
   • GDS Verify sounds interesting
   • Multi-factor Authentication (key fobs, phone apps creating tokens)

I will stop blurting out now...

[edent]

Interesting challenge. We have a couple of questions for you.

1. Which department do you work for?
2. Is this challenge around Civil Servants logging in to Government systems, or about external users interacting with systems? Or both?
3. Are there any standards that you've seen which already cover this? Or are similar to this?

If you prefer, you can reply to me via email. Terence.Eden AT digital DOT cabinet-office DOT gov DOT uk

[Lawrence-G]

Some of the points here are touched on in the conversation around the challenge posted last year here the proliferation in the number of usernames and passwords for services creating a user need for a common auth method. Mat Johnsons' comment of 'breaking down into it's components; Authentication, Authorisation, Accounting and Federation' in particular.

[mattjohnsongds]

Thanks for the mention; (personally) I think we can federate the responsibility of Authentication out to the relevant departments/agencies/entities and operate on a model of mutual trust. I know this is easily achievable given the work I've done in a similar area in the DWP (I'm now at GDS). But at the moment there are no COTS packages geared up to deliver exactly this and typically AAA servers/gateways are traditionally expensive and closed source. With Authentication happening at the site of a trusted IDP, Authorisation is free to occur at the point of use and Accounting can occur at the same point (or further down the line). To grease the wheels of this proposal I would be happy to put together a straw man proposal/RFC which can be debated/scrutinised?

[Lawrence-G]

It would be great if you could put together a proposal/RFC for an open standards approach to meeting this challenge and move the discussion on to possible solutions. If your proposal could be based on the needs outlined in this and the previous challenge that would be good or if you feel the need to refine the challenge, feel free to do so.

[mattjohnsongds]

Cool, thanks for the feedback - I've contributed to both discussions and other related discussions in this domain. So, my approach would not be to prescribe a particular technology but instead, as the Challenge Owner identifies, give some guidance on a platform to enable a route to serving the user needs from both discussions in the form of a system that GDS (or another Government Department) may procure or build, but that operates on Open Standards. Really sorry about the size of this, also it's based on a (customised) version of the Rust RFC template since I couldn't find a GDS one.

DRAFT RFC: Summary

Guidance relating to enabling cross-party Authentication, Authentication and Accounting (AAA) that utilises a federated model of trusted IDPs for Authentication and a dis-aggregated model Authorisation and Accounting. This guidance will potentially enable Customers, Operational Staff and Service-to-Service AAA functionality in order to provide a consistent experience for integration of Authentication functionality and simultaneously maintain a non-intrusive user-experience.

Motivation

There are many outstanding requests on the UK Government Tech & Data Standards pages regarding SSO, SAML, Authentication and Authorisation. Whilst this proposal will give guidance on an anticipated design, it does not seek to be overly prescriptive with implementation details and it is anticipated that the implementer will decide the best route based on this guidance. This guidance also acknowledges it is not suitable for all use-cases where AAA functionality is desired; for example, GDS Verify may be more than adequate for your user needs.

The motivation for this RFC emerges from discussions relating to inter-departmental AAA functionality.

Detailed design

Much of this design centers on a AAA Gateway (or Server) delivering the functionality described. The AAA Gateway is layered in front of the service being secured, that is; network packets coming from a user requesting access to a service will hit the AAA Gateway before hitting the service, the service is not directly contactable by the user requesting access.

The AAA Gateway may be a customised reverse-proxy, a COTS AAA package, an API Gateway or a Web Application Firewall (WAF).

A user requesting access may be a departmental user with appropriate clearance, or an upstream service accessing a downstream service with a relayed Access Token.

Authentication must occur at the IDentity Provider (IDP) of the user requesting access.

Authorisation must occur at the AAA Gateway.

Accounting may occur at any point.

The AAA Gateway must allow Authentication with at least one IDP, and may allow more IDPs depending on the configuration of the AAA Gateway and/or the context of the call.

Process

• The user requesting access makes a request of an URI
  • e.g. A HTTP GET request from a browser
  • e.g. A HTTP PUT request from an upstream service
• The AAA Gateway checks for an Access Token
  • e.g. A JWT token describing the users IDP, Access Rights, Unique Identifier at their IDP and an Expiry Date for this Access Token
• When no Access Token is present, the Authentication process must be invoked
  • e.g. SAML2 process with ADFS - which could make a NTLM browser request for SSO functionality
  • e.g. LDAP process for third party suppliers/contractors
  • e.g. OAuth for service-to-service or third-party users - such as relaying GitHub issues to an internal governance process service
  • e.g. Anonymous authentication will still result in an Access Token for Authorisation and Accounting purposes
• When Authentication is complete, the Access Token must be issued to the user requesting access
  • e.g. As a HTTP-header value
  • e.g. As a HTTP-Only & Secure Cookie with domain & path constraints
• When an Access Token is present, the Authorisation process is invoked
  • e.g. Where the Access Token is a JWT, we may perform signature verification, token lifetime checks and revocation checks
• Upon successful Authorisation, the original request from the user requesting access is relayed to the service endpoint along with the Access Token
  • e.g. The HTTP request is passed along (in a reverse-proxy fashion) - the service is free to reuse the token for downstream requests
• All replies from the service endpoint are relayed back to the user requesting access
• AAA Gateways/Services downstream of the current AAA Gateway/Service must reuse this process; potentially allowing for elevation to occur and defense in depth.
  • e.g. Where the user has insufficient Access Rights

Properties of this design

• Federated Authentication - This guidance does not prescribe a preferred IDP, it may even be possible to use many different IDPs depending on the configuration of the AAA gateway or the context of the request.
• Nonrepudiation - The Access Token may include attributes that identify the user uniquely and ensure that the token is allocated only to that user for a fixed period of time. It is practical that all calls through the AAA Gateway could be attributed to an originating user (even calls relayed downstream to other services).
• Defense in Depth - This guidance would add another restrictive layer to the "defense-in-depth" argument and does not exclude the usage of WAFs, Firewalls, Reverse-Proxies etc.
• Works for the Web - This guidance is only relevant to HTTP(S) traffic and does not advocate proprietary formats or behaviour incompatible with this type of transport. It is conceivable that the Access Token could be of any Open format and transported as a HTTP header, URI querystring argument or payload body of a POST request.
• Stateless Services - This guidance does not suggest a format for the Access Token (or Refresh Token) but by using a cryptographically signed format (e.g. JWT/JWE/SAML) it is possible that all of the necessary information intended to relay the security context could be encapsulated within the Access Token which would enable a stateless architecture.
• SSO - This guidance does not prescribe a preferred authentication model, but by utilising HTTP concepts it may be possible to introduce SSO functionality depending on the IDP (e.g. for ADFS authentication using SAML it would be possible to use NTLM browser authentication).

How We Teach This

There are layers of some complex concepts at work in this guidance, principally this guidance could be expressed as a flow-diagram that shows upstream and downstream communication between components for a variety of use-cases, but in many use cases it is easiest to think of the AAA Gateway layer simply as a reverse-proxy with some rules and behaviour.

If this RFC gains traction, I (or someone) can create the necessary flow-diagrams for a variety of use-cases.

Drawbacks

• SSL termination - In order to read the HTTP-headers it would be necessary to perform SSL termination at (or before) the AAA gateway, however it could be re-established to downstream services.
• Increased latency - As another point in the HTTP communication pipeline there would undoutedbly be (small) additional latency.
• Single point of failure - This can be mitigated if the AAA Gateway can be clustered (or load-balanced) when using a stateless architecture (e.g. the Authorisation context is encapsulated within the Access Token).
• Trust - Establishing a trust relationship may involve some leg-work and additional communication/administration.

Alternatives

• Since this is guidance only it is not yet necessary to discuss implementation alternatives.

Unresolved questions

• What (Open) format for the Access Token?
• Do we use Refresh Tokens?
• How should the Access Token be expressed? As an HTTP Header?
• Does anything in the marketplace do this already?
• SSL termination is tricky business, (if we build it) do we build on top of an established reverse-proxy?

User need

The user need presented by the Challenge Owner discusses what amounts to essentially a simplification of Authentication & Authorisation. This guidance seeks to address this by utilising the Authentication mechanisms and user-database that the Agency/Organisation already has, and should be familiar with. User management is federated out to that Agency/Organisation and this guidance aims to reduce the impact of attack by having many databases of users instead of "a single database of users".

To be clear; this guidance would present a system such that the Organisation/Agency only needs to implement one Authentication mechanism against their own IDP. Authorisation is a wholly different activity that the Agency/Organisation do not need to implement. Accounting may happen at any party, at any point.

Functional needs

1. This guidance does not offer a "silver-bullet" singular approach, but instead supports many Authentication mechanisms that would be appropriate for the usage context. The Authorisation mechanism is consistent.
2. As above, this RFC proposes many different Authentication mechanisms depending on the context of usage.
3. This guidance allows for the AAA Gateway to be clustered, stateless, is IDP agnostic and should support open-standards for Authentication. In theory LDAP, ADFS and OAuth could all be used as independant IDPs to secure a single service.
4. This guidance gives a clear separation of responsibilities for where and how Authentication and Authorisation occur.
5. This guidance does not discuss technological implementation details, but it is the opinion of the author that if it were to be built (or procured) it should be an open-source system that relies on tried-and-tested mechanisms (e.g. NGINX)
6. This is for the reader/reviewer to interpret.
7. This guidance suggests that Authentication would be pluggable/changeable and that Access Levels could determine escalation behaviour. It may also be permissible that Authentication mechanisms are chained in order to give MFA
   • e.g. I am a citizen wishing to update my address with HMRC and I Authenticate using GDS Verify (LOA 1). I then wish to view my bank/payment details. The AAA Gateway would deny the request and/or challenge for escalation. I may choose to escalate with GDS Verify for LOA 3.
   • e.g. I am DV Cleared Operational Staff at the NCA, I want to send an internal memo about the air conditioning and I authenticate with LDAP username & password. In the same session, I also want to read all TOP SECRET memos. The AAA Gateway would deny me access and/or challenge for escalation. I may choose a biometric via FIDO U2F for TOP SECRET clearance.

[mattjohnsongds]

FYI: I recognise this is a pattern and not advocating a particular open-standard - this is in response to the original Challenge Owners request to "create a framework". However, at yesterdays GDS Architecture meetup it appears that Peter Chamberlin has been working on something very similar, as has Home Office, NCSC & DWP. I have asked for feedback from the wider Architecture community on the cross-government Slack channel and I'll be meeting up with Peter this afternoon to discuss the finer points of the GDS implementation.

[mattjohnsongds]

CTS have some direction which advocates SAML2 and OIDC - GDS & Home Office appear to be using KeyCloak for this but IMHO it doesn't serve as a true AAA Gateway. I'm aware that I've probably warped the original intention of this issue to suggest a solution, rather than a pattern (or open format).

In the spirit of utilizing open-formats it's probably sufficient to point to the CTS guidance of OIDC & SAML2.

In the spirit of practicality (for other government departments) - I think they really need a solution centered on federation, for which the best direction I can point to would be the Accessing GaaP product (which is currently probably not mature enough) and the CTS team which are looking at sourcing some kind of product to fill this space.

[Lawrence-G]

We have had no further submissions from other departments requesting an authentication solution. This challenge will be put on hold for the time being.