wiki:T12_Security/ESG/LoginAttributeRequestAndAuthorizationPushAndPullModel

Version 3 (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)

User Registration for new Dataset

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

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 AR5 dataset from the BADC site.

Outcome

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

  1. ESG gateway e) redirects the user's browser to the authorization request form hosted at the Gateway f).
  2. The user completes details, agrees to the terms of a usage policy, submits and awaits a response.
  3. According to the approval criteria, the user is granted or denied the AR5_ACCESS attribute.
  4. 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.
  5. 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.

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

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.