wiki:T12_Security/ESG/LoginAttributeRequestAndAuthorizationPushAndPullModel

Version 15 (modified by pjkersha, 11 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

  1. User Registration for new Dataset. (User attribute assignment)
  2. Login and Authorization (using push and pull model for user attribute handling)










1) Login and Authorization (using push and pull model for user attribute handling)

Description

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.

Actors

  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 attribute attributeA;
    • has a service which a PDP can invoke to find out if a given user has registered for attributeA

Assumptions

  • 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.

Triggers

A user attempts to access a secured datasetA from the BADC site.

Outcome

NCAR user is granted access secured datasetA from BADC 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 is invoked to allow or deny access to the resource.
  9. The PEP passes the NCAR user's attributes to the BADC PDP so that it can make an access control decision.
  10. The PDP checks the user's attributes to see if attributeA is present.
  11. attributeA is not present so the PDP queries the BADC Attribute Service passing the user's ID.
  12. The BADC Attribute Service checks to see if the NCAR user is registered with attributeA.
  13. The Attribute Service returns a response to the PDP that the NCAR user is registered for attributeA.
  14. The PEP grants access to the data.
  15. Download of datasetA commences for the NCAR user.

2) User Registration for new Dataset (User attribute assignment)

Description

This use case describes the browser based profile for a user to register to access a new dataset.

Actors

  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 Attribute Service responsible for access attribute assignment. This site:
    • hosts an attribute request form where users can register, agree to terms and be allocated the attribute attributeA to enable them to access datasetA;
    • has a service which a site hosting datasetA data can invoke to find out if a given user is registered for attributeA

Assumptions

  • Use case for browser based access
  • user is not logged in to NCAR site
  • user doesn't have authorization for datasetA access
  • control to datasetA is governed by an attribute called attributeA.

Triggers

A user requires access to datasetA from the BADC site.

Outcome

User is granted access rights to secured datasetA data from BADC site.

Normal Course

  1. The BADC site redirects the user's browser to the authorization request form hosted at the BADC.
  2. The user completes details, agrees to the terms of a usage policy, submits and awaits a response.
  3. The details from the form are submitted to the BADC Attribute Service.
  4. The user is approved for access to datasetA. (This may an immediate decision or it may require submission to an approval panel).
  5. When approved, the Attribute Service creates a user profile for this user containing attributeA.
  6. If approval is immediate, the BADC can redirect the NCAR user to the page for datasetA download.
  7. If approval requires submission to an approval panel, then the BADC site lets the user know that this is the case and that they will be informed of a decision by e-mail (or other means).