NDG Security

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

OpenID Login and AR5 Authorization Request Form at IdP


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 is the first iteration of this use case. The authorization form is sited at the IdP. This is counter to the ESG proposed architecture whereby an authorization form for a dataset would be hosted at a site which has repsonsibility for securing that data.


  • ESG Site serving secured AR5 data
  • BADC User i.e. user belongs to an organisation trusted by the ESG site.
  • BADC site (OpenID Provider where user is registered)
  • Client browser


  • user is not logged in to ESG site
  • user doesn't have AR5 authorization
  • 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 site and selects an AR5 secured dataset
  2. The ESG site blocks access because user is not logged in
  3. The site redirects user to page with form to select the user's OpenID provider
  4. The user enters their BADC OpenID identifier or selects BADC from a list of sites (ID Select mode)
  5. The user's browser is redirected to the BADC. They login.
  6. The BADC OpenID provider redirects browser back to ESG site passing user authorization attributes in addition to the usual OpenID protocol message response content.
  7. The ESG site checks the user's authorization attributes for the AR5_ACCESS attribute.
  8. AR5_ACCESS is not present
  9. ESG site redirects user's browser to the BADC authorization request form.
  10. User completes details and submits and awaits a response.
  11. According to the approval criteria, the user is granted or denied the AR5_ACCESS attribute.
  12. If approved, the user's home site (the BADC) updates the user's profile adding AR5_ACCESS to it's list of authorisation attributes.


At point 9) we'd like to present the authorization form so that the user can request the AR5_ACCESS attribute but the authorization request form should be served from the user's home site (the BADC) not the ESG site they're visiting.*

We envisage that the ESG site would know the address of this authorization request page from:

  1. an additional attribute sent by the BADC OpenID provider over the OpenID interface or
  2. the ESG site keeps a record of the location of an authorization request form URL for each site it trusts in its whitelist.
  • a) is likely to be less error prone because the maintainer of the authorization page sends the URL.
  • SSL could be used to enable the ESG site to check that it is calling a valid BADC URL.

The last step is dependent on the approval method. If there was immediate approval, a redirect could send the user back to the ESG site to enable them to access the AR5 data. This is not likely given the approval methods we've looked at are going to involve some delay.

* Last ESG-NDG Telecon 24/07/08: Luca expects that between ESG partners the convention will be for the data provider site to host the authorization form.