Library

Browse and search developer information

Pattern 4: Federated Identity, Broker AuthZ

Pattern Description

This is a variation on pattern 3, and adds a national broker to establish system-to-system trust between the RP and the Resource Owner. This broker can carry out the token checks to ensure the request has been authorised before allowing it through, meaning the resource server no longer needs to do this check.

Benefits

  • Provides a single mechanism for establishing system-to-system trust between sharing systems – backed by a light-weight national assurance process to make use of the national PKI.
  • Can be built to address local needs, but within a national framework that establishes proven types and levels of authentication.
  • Provides a single enforcement point for API calls flowing through the broker, ensuring nationally agreed controls are applied consistently.

Concerns

  • Requires up-front work to develop a national framework, and establishment of a national assessment process to assure local solutions in order to grant them “trusted” status and federate with them.
  • Would only do authorisation against nationally agreed policies using information held about the user nationally – e.g. would not do checks that rely on user attributes only held in the local systems, such as legitimate relationship checks