wiki:T12_Security/ESG/LoginAttributeRequestAndAuthorizationPushAndPullModel

Version 30 (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 for Login, User Registration and Authorization

These use cases aim to demonstrate the proposed solution for access control following recent discussions with the ESG development team (4 Sept 2008). The aim is to demonstrate a proposed push and pull model for user attribute handling between ESG federation members.

Key to this:

  • ESG IdPs (OpenID Providers) hold IdP specific attributes for their users.
  • On an authentication request, an ESG IdP may push attributes back to the Relying Party (Data Provider site or gateway) that requests them. These may be used for access control decisions. However,
  • Individual Attribute Services may be responsible for the allocation of attributes that protect a given set of resources.
  • Users wishing to access those resources are directed to these Attribute Services in order to register
  • In order to make an access control decision, an Attribute Service (may in some cases be more than one) may be queried to pull user attributes.
  • User attributes then are held at the user's IdP but some may also be held independently at Attribute Services.

Only a browser based profile is considered here.

  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

This use case demonstrates the concept of an Attribute Service associated with a resource or resources to be protected. The user is registered at this Attribute Service. To make an access control decision, the Attribute Service is queried to see if the user has the required attribute to access the resource.

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 the 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 (name for this in ESG terms?). This enforces access control decisions for a given resource or resources. It does so by requesting that a PDP make an access control decision on its behalf. It then enforces that decision by allowing or denying access.
  8. BADC Attribute Service responsible for attribute assignment and querying. This service:
    • enables a user to register for access to datasetA, agree to terms and be allocated the attribute attributeA which determines access to datasetA;
    • has a service which a PDP can invoke to find out if a given user has registered for attributeA

Assumptions

  • This is a use case for browser based access only
  • The user is not logged in to the NCAR or BADC sites
  • Control to datasetA is governed by an attribute attributeA.
  • The user is registered with attributeA at the BADC Attribute Service.

Triggers

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

Outcome

NCAR user is granted access secured datasetA from the 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.
  6. The user logs in.
  7. The NCAR IdP may prompt the user to check that they agree to certain attributes being pushed back to the BADC site.
  8. If the user agrees to it, the NCAR IdP redirects the browser back to the BADC site passing user attributes in addition to the usual OpenID protocol message response content.
  9. The BADC site's PEP is invoked to allow or deny access to the resource.
  10. The PEP passes the NCAR user's attributes to the BADC PDP so that it can make an access control decision.
  11. The PDP checks the user's attributes to see if attributeA is present.
  12. attributeA is not present so the PDP queries the BADC Attribute Service passing the user's ID.
  13. The BADC Attribute Service checks to see if the NCAR user is registered with attributeA.
  14. The Attribute Service returns a response to the PDP that the NCAR user is registered for attributeA.
  15. The PEP grants access to the data.
  16. Download of datasetA commences for the NCAR user.

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

Description

This is an extension of the last use case using the same trigger point but in this scenario the user is not registered for access to datasetA. The use case continues from point 13) of the last use case but with the assumption that access was denied because the user is not registered with BADC Attribute Service for access.

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 (name for this in ESG terms?). This enforces access control decisions for a given resource or resources. It do so by requesting that a PDP make an access control decision on its behalf. It then enforces that decision by allowing or denying access.
  8. 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

  • This is a use case for browser based access only
  • The user is not logged in to NCAR site
  • Control to datasetA is governed by an attribute attributeA.
  • The user is not registered for access to datasetA.

Triggers

A user requires access to datasetA from the BADC site.

Outcome

User is registered for access to secured datasetA data from BADC site.

Normal Course

Continuing from point 13) in the last use case:

  1. The Attribute Service returns a response to the PDP that the NCAR user is not registered for attributeA.
  2. The BADC site redirects the user's browser to a registration form hosted at the BADC.
  3. The user completes details, agrees to the terms of a usage policy, submits and awaits a response.
  4. The details from the form are submitted to the BADC Attribute Service (The Attribute Service could itself host the form)
  5. The user is approved for access to datasetA. (This may be an immediate decision or it may require submission to an approval panel).
  6. When approved, the Attribute Service creates a user profile for this user containing attributeA.
  7. If approval is immediate, the BADC site can redirect the NCAR user to the page for datasetA download.
  8. 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 by other suitable means).