Skip to main content

Authentication and authorisation deployment patterns

There are a number of approaches to deploying standards-based authentication and authorisation.  Making the right choice is central to making sure that only the right people can access health and care data.

Authentication, sometimes known as AuthN, is how a system checks that the user is who they claim to be, in order to access a system.

Authorisation, sometimes known as AuthZ, is checking which services an authenticated user has access to.

About the patterns

The patterns presented here are different ways of ensuring that only the right people can access health and care data.

Every system needs to choose a pattern which works best for them, taking into account the benefits and limitations of each approach.

Some systems will need to use a combination of patterns.

All the patterns are designed for services which:

  • need some level of authorisation (so aren't open to everyone)
  • will use the OpenID connect standard
Terms used

Within these patterns, the following terms are used

Term Definition
Authentication or AuthN How a system checks that the user is who they claim to be, in order to access a system
Authorisation or AuthZ Checking which services an authenticated user has access to
End user or 'resource owner' This is the user who is being asked for identity information
User agent The software, app, or browser being user by the End user to reach the resource they need
Client application or 'relying party' The application accessed by the User agent which makes the request to one or more resource providers
Resource provider The service which holds the data the End user wants
Authentication server The service which checks the End user's credentials and provides them an identity token
Authorisation server or 'token provider' The service which applies any authorisation policy controls and permissions
Identity provider or IDP The service which holds identity information of registered End users
Federation server A service which federates identities used by 3rd party Authentication servers to allow identities to be linked.   It allows user attributes from multiple Identity providers to use a common model for ID tokens
Public key infrastructure or PKI A set of roles, policies, and procedures used to manage digital certificates and encryption of data

Appropriate patterns

The appropriate patterns will depend on the systems in use, but these tables show some suggested patterns by application.

System access (where users log on to the system)
Local authentication and authorisation Local authentication, national authorisation National authentication, Local authorisation National authentication and authorisation
Local system access 1. All local - 5. National identity, Local AuthZ 7. All national
National portal - 3. Federated identity, national AuthZ - 7. All national

 

System to system API calls
Local authentication and authorisation Local authentication, national authorisation National authentication, Local authorisation National authentication and authorisation
Direct local integration 1. All local 3. Federated identity, national AuthZ 5. National identity, Local AuthZ

6. Federated identity, Local AuthZ
7. All national
National service (e.g. SCR) - 3. Federated identity, national AuthZ - 7. All national
Nationally brokered (SSP) 2. Local only, simple broker 4. Federated identity, Broker AuthZ 5. National identity, Local AuthZ

6. Federated identity, local AuthZ
8. National identity, broker AuthZ

1. All local

This is a fully local version of both authentication and authorisation, which might be within a single organisation, or make use of shared regional resources between a number of local organisations.

Architectural diagram of the all local authorisation pattern

Benefits include

  • providing a single way of establishing system-to-system trust for sharing
  • being able to be built to address specific local needs
  • all aspects of access control managed locally

If you are considering this pattern, you should be careful that

  • this only provides the ability to share within the organisation(s) who implement this system, and sharing with other areas would require another pattern, like federated identities
  • it does not provide a way of accessing local data or services, which would need a second pattern, and may require users to log in again

2. Local only, simple broker

This is closely related to the local only pattern, but adds a simple broker to establish trust between the client and Resource provider systems.   

Architectural diagram of the local only, simple broker authorisation pattern

Benefits include

  • providing a single way of establishing system-to-system trust for sharing
  • having a light-weight national assurance process to make use of the national public key infrastructure
  • being able to be built to address specific local needs
  • all aspects of access control managed locally

If you are considering this pattern, you should be careful that

  • this only provides the ability to share within the organisation(s) who implement this system, and sharing with other areas would require another pattern, like federated identities
  • it does not provide a way of accessing local data or services, which would need a second pattern, and may require users to log in again

3. Federated identity, national AuthZ

This pattern allows local identity providers to be used to manage and authenticate users, but has a trust relationship with a national service.

This means that local identities can be linked to national identities for use outside the local area.   

The identities can then be used to authorise access using national authorisation servers.

Architectural diagram of the federated identity, national AuthZ authorisation pattern

Benefits include

  • being able to be built to address specific local needs, but within a national framework with established types and levels of authentication
  • local solutions can be federated and trusted by local systems
  • potential to link to authentication services in other regions, allowing use outside the local area

If you are considering this pattern, you should be careful that

  • work is required to develop a national framework, and to establish a national assessment process to assure local solutions in order to grant 'trusted' status and federate with them
  • authorisation is only against nationally agreed policies, and information held nationally, meaning that local user attributes might not be taken into account

4. Federated identity, broker AuthZ

This is a variation on federated identity and national AuthZ, adding a national broker to establish system-to-system trust.

The broker can carry out token checks between the resource provider and resource owner, ensuring that the request has been authorised before allowing it.

This means that the resource server no longer needs to do this check.

Architectural diagram of the federated identity, broker AuthZ authorisation pattern

Benefits include

  • provides a single way of establishing system-to-system trust
  • backed by a light-weight national assurance process to make use of the national public key infrastructure
  • can be built to address local needs, but within a national framework
  • provides a single enforcement point for API calls flowing through the broker, ensuring nationally agreed controls are in place

If you are considering this pattern, you should be careful that

  • work is required to develop a national framework, and to establish a national assessment process to assure local solutions in order to grant 'trusted' status and federate with them
  • authorisation is only against nationally agreed policies, and information held nationally, meaning that local user attributes might not be taken into account

5. National identity, local AuthZ

This pattern uses national authentication and identity, and uses that within local systems to grant access to resources.

Architectural diagram of the national identity, local AuthZ authorisation pattern

Benefits include

  • provides a simple way of managing user authentication
  • takes away the need to have local access management solutions
  • provides a national 'single sign-on' capability 
  • allows users to use multiple systems, whilst only logging on once, using an authentication session token

If you are considering this pattern, you should be careful that

  • it allows local control over authorisation polciies for controlling access to resources
  • it does not itself allow access to national systems, but could allow for automatically re-authorising the ID token with a national authorisation server (as in 7: all national) to give this capability

6. Federated identity, local AuthZ

This is a variation on pattern 3: federated identity, national AuthZ, which allows local identity providers to be used to manage and authenticate users.

Architectural diagram of the federated identity, local AuthZ pattern

By establishing a trust relationship with a national service, it allows for local identities to be linked to national ones for use outside the local area.   These are identities are then used to authorise access using a local authorisation server.

Benefits include

  • can be built to address local needs
  • sits within a national framework that establishes proven types and levels of authentication

If you are considering this pattern, you should be careful that

  • it allows local control over authorisation polciies for controlling access to resources
  • it does not itself allow access to national systems, but could allow for automatically re-authorising the ID token with a national authorisation server (as in 7: all national) to give this capability

7. All national

This pattern uses national components to manage all authentication and authorisation of users.  

Architectural diagram of the all national authorisation pattern

Local systems can then use the tokens given out by the national services to make access control decisions, without having to implement any local authentication or authorisation services.

Benefits include

  • very simple access controls for local systems
  • no need to do any local user management or authorisation checks
  • able to rely on national services carrying out basic checks
  • provides a national 'single sign-on' capability
  • allows users to log on once, and use multiple systems through an authentication session token
  • reduces costs for local or regional solutions

If you are considering this pattern, you should be careful that

  • it takes authorisation away from local systems, although tokens can be inspected and additional checks undertaken to block if necessary
  • could introduce confusion if a client is authorised nationally, but blocked locally
  • it will only authorise against nationally agreed policies, using nationally held information, and will not use locally held information

8. National identity, broker AuthZ

This pattern uses national components to manage all authentication and authorisation of users.   

Local systems can then use the national tokens to make access control decision without having to implement any local authentication or authorisation services.

Architectural diagram of the national identity, broker AuthZ authentication pattern

Benefits include

  • provides a single way of establishing system-to-system trust
  • backed by a light-weight national assurance process to make use of the national public key infrastructure
  • provides a single enforcement point for API calls flowing through the broker, ensuring nationally agreed controls are in place
  • reduced costs for local or regional solutions

If you are considering this pattern, you should be careful that

  • it takes authorisation away from local systems, although tokens can be inspected and additional checks undertaken to block if necessary
  • could introduce confusion if a client is authorised nationally, but blocked locally
  • it will only authorise against nationally agreed policies, using nationally held information, and will not use locally held information
Last edited: 3 July 2019 1:53 pm