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


NDG Security


ESG - NDG Security Use Cases

Login, Attribute Request and Authorization (using push and pull model for user attribute handling)


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. siteA owns the resource and the ultimate access policy that is enforced on that resource.
  2. SiteB hosts an IdP for a user's !OpenID
  3. siteC's for the user's registration and VO-attributes/access-policy,
  1. NCAR User i.e. user belongs to a member organisation of the ESG federation.
  2. Client browser
  3. NCAR IdP (Identity Provider or in the language of OpenID an 'OpenID Provider' where the NCAR user is registered)
  4. NCAR user profile. A set of information about the NCAR user held by the NCAR IdP. This could be for example a database record.
  5. BADC site serving secured dataset datasetA.
  6. BADC PDP (Policy Decision Point), a service that makes an access control decision based on the attributes controlling access to a given resource and the user attributes available. (Is this a Resource Policy Service in ESG terminology?)
  7. BADC PEP (Policy Enforcement Point) or gatekeeper. This enforces access control decisions for a given resource or resources. It makes a request to a PDP to make an access control decision and then enforces that decision by allowing or denying access.
  8. BADC Attribute Service responsible for 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.


  • Use case for browser based access
  • user is not logged in to NCAR 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 attempts to access a secured AR5 dataset from the BADC site.


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

Normal Course

  1. The NCAR user browses the BADC site and selects a secured dataset datasetA for download.
  2. The BADC site blocks access because the user is not logged in
  3. The BADC site redirects the user to page with a form to select the user's IdP (OpenID Provider)
  4. The NCAR user submits their NCAR OpenID identifier
  5. The user's browser is redirected to the NCAR IdP. They login.
  6. The NCAR may prompt the user to check that they agree to certain attributes being pushed back to the BADC site.
  7. The NCAR IdP redirects the browser back to the BADC site passing user attributes in addition to the usual OpenID protocol message response content.
  8. The BADC site's PEP
  9. ESG gateway e) redirects the user's browser to the authorization request form hosted at the Gateway f).
  10. The user completes details, agrees to the terms of a usage policy, submits and awaits a response.
  11. According to the approval criteria, the user is granted or denied the AR5_ACCESS attribute.
  12. 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.
  13. 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.