Version 1 (modified by pjkersha, 12 years ago) (diff)


NDG Security

Home | Research | Architecture | Documentation | Downloads | Discussion | OMII-UK | ESG and IPCC AR5 | DEWS | Admin Quick Start

ESG - NDG Security Use Cases

OpenID Login and AR5 Authorization Request


Browser based federated access to secured AR5 data and allocation of AR5 access rights to a registered user. A draft based on Section C 3d) of the Architectural Assumptions document (v0.3)

This use case is based on the proposed ESG architecture for user attribute assignment. Particular ESG gateways have responsibility for attribute assignment to users. Key to this use case, these gateways have the capability to invoke a service at the user's IdP and add or remove the given ESG attribute(s) for which they have authority.


  1. Client browser
  2. BADC User i.e. user belongs to an organisation trusted by the ESG site.
  3. BADC IdP (Identity Provider or in the language of OpenID an 'OpenID Provider' where the BADC user is registered)
  4. BADC user profile. A set of information about the BADC user held by the BADC IdP. This could be for example a database record.
  5. ESG Gateway serving secured AR5 data. Possibly multiple gateways will serve AR5 data but only one gateway will have responsibility for assigning AR5 access attributes to users. See next item.
  6. ESG Gateway responsible for AR5 access attribute assignment. This site:
    • hosts an authorization where users can register, agree to terms and be allocated the AR5 access attribute to their personal profile.
    • Has a service which can contact the user's IdP and request to add or remove the the AR5 attribute from the user's profile.


  • user is not logged in to ESG site
  • user doesn't have authorization for AR5 access
  • control to AR5 data is governed by a federation wide attribute called AR5_ACCESS.


A user accesses a secured AR5 dataset from the ESG site.


User is granted authorization to access secured AR5 data from ESG site.

Normal Course

  1. The user browses ESG gateway e) and selects an AR5 secured dataset
  2. The ESG gateway e) blocks access because the user is not logged in
  3. The site redirects user to page with a form to select the user's OpenID provider
  4. The user enters their BADC OpenID identifier
  5. The user's browser is redirected to the BADC IdP. They login.
  6. The BADC IdP redirects the browser back to the ESG site passing user authorization attributes in addition to the usual OpenID protocol message response content.
  7. The ESG gateway e) checks the user's authorization attributes for the AR5_ACCESS attribute. AR5_ACCESS is not present.
  8. ESG gateway e) redirects the user's browser to the authorization request form hosted at the Gateway f).
  9. The user completes details, agrees to the terms of a usage policy, submits and awaits a response.
  10. According to the approval criteria, the user is granted or denied the AR5_ACCESS attribute.
  11. If approved, Gateway f) invokes a service running at the BADC IdP making a request to update the user's profile adding AR5_ACCESS to it's list of authorization attributes.
  12. The BADC IdP sends a response to Gateway f) indicating that the user's profile has been updated. The user may now access data secured with the AR5_ACCESS attribute.