Changes between Version 18 and Version 19 of T12_Security/ESG/LoginAttributeRequestAndAuthorizationPushAndPullModel


Ignore:
Timestamp:
08/09/08 15:08:31 (11 years ago)
Author:
pjkersha
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • T12_Security/ESG/LoginAttributeRequestAndAuthorizationPushAndPullModel

    v18 v19  
    22= ESG - NDG Security Use Cases for Login, User Registration and Authorization = 
    33[[PageOutline]] 
     4These use cases aim to demonstrate a proposed solution for access control following discussions with the ESG development team.  The aim is to demonstrate a proposed push and pull model for user attribute handling between ESG federation members.  Only a browser based profile is considered here.  Key to this: 
     5 * ESG IdPs (OpenID Providers) hold IdP specific attributes for their users. 
     6 * 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, 
     7 * Individual Attribute Services may be responsible for the allocation of attributes that protect a given set of resources. 
     8 * Users wishing to access those resources are directed to these Attribute Services in order to register  
     9 * When making an access control decision, an Attribute Service (may in some cases be more than one) may be queried to see if the user making the request is registered for the required attribute or attributes. 
     10 * User attributes then are held at the user's IdP but some may also be held independently at Attribute Services where a user choses to register. 
     11 
    412 1. [wiki:T12_Security/ESG/LoginAttributeRequestAndAuthorizationPushAndPullModel#a1LoginandAuthorizationusingpushandpullmodelforuserattributehandling User Registration for new Dataset.  (User attribute assignment)] 
    513 1. [wiki:T12_Security/ESG/LoginAttributeRequestAndAuthorizationPushAndPullModel#a2UserRegistrationfornewDatasetUserattributeassignment Login and Authorization (using push and pull model for user attribute handling)] 
     
    1321[[BR]] 
    1422[[BR]] 
    15  
     23[[BR]] 
    1624 
    1725---- 
    18  
    1926 
    2027=== 1) Login and Authorization (using push and pull model for user attribute handling) === 
    2128 
    2229==== Description ==== 
    23 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) 
    24  
    25 This use case is based on the proposed ESG architecture for user attribute assignment.  Particular ESG gateways have responsibility for attribute assignment to users.   
     30This 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. 
    2631 
    2732==== Actors ==== 
     
    3035 a. NCAR IdP (Identity Provider or in the language of OpenID an 'OpenID Provider' where the NCAR user is registered) 
    3136 a. NCAR user profile.  A set of information about the NCAR user held by the NCAR IdP.  This could be for example a database record. 
    32  a. BADC site serving secured dataset datasetA. 
    33  a. 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?) 
    34  a. 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.   
    35  a. BADC Attribute Service responsible for access attribute assignment.  This site: 
    36    * hosts an authorization where users can register, agree to terms and be allocated the attribute attributeA; 
     37 a. BADC site serving the secured dataset ''datasetA''. 
     38 a. 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?'') 
     39 a. 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.   
     40 a. BADC Attribute Service responsible for attribute assignment and querying.  This service: 
     41   * enables a user to register for access to datasetA, agree to terms and be allocated the attribute attributeA which determines access to datasetA; 
    3742   * has a service which a PDP can invoke to find out if a given user has registered for attributeA 
    3843 
    3944==== Assumptions ==== 
    40  * Use case for browser based access 
    41  * user is not logged in to NCAR site 
    42  * user doesn't have authorization for AR5 access 
    43  * control to AR5 data is governed by a federation wide attribute called ''AR5_ACCESS''. 
     45 * This is a use case for browser based access only 
     46 * The user is not logged in to NCAR site 
     47 * Control to ''datasetA'' is governed by an attribute ''attributeA''. 
     48 * The user is registered with ''attributeA'' at the BADC Attribute Service. 
    4449 
    4550==== Triggers ==== 
     
    4752 
    4853==== Outcome ==== 
    49 NCAR user is granted access secured datasetA from BADC site. 
     54NCAR user is granted access secured datasetA from the BADC site. 
    5055 
    5156==== Normal Course ==== 
     
    5459 1. The BADC site redirects the user to page with a form to select the user's IdP (OpenID Provider) 
    5560 1. The NCAR user submits their NCAR OpenID identifier 
    56  1. The user's browser is redirected to the NCAR IdP.  They login. 
     61 1. The user's browser is redirected to the NCAR IdP.   
     62 1. The user logs in. 
    5763 1. The NCAR may prompt the user to check that they agree to certain attributes being pushed back to the BADC site. 
    5864 1. The NCAR IdP redirects the browser back to the BADC site passing user attributes in addition to the usual OpenID protocol message response content. 
     
    7076 
    7177==== Description ==== 
    72 This use case describes the browser based profile for a user to register to access a new dataset. 
     78This is extension of the last use case using the same trigger point but in this scenario the user is not registered for access to datasetA:  This use case continues from point 13) in the last use case but with the assumption that access was denied because the user is not registered for access. 
    7379 
    7480==== Actors ==== 
     
    7884 a. NCAR user profile.  A set of information about the NCAR user held by the NCAR IdP.  This could be for example a database record. 
    7985 a. BADC site serving secured dataset datasetA. 
     86 a. 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?'') 
     87 a. 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.   
    8088 a. BADC Attribute Service responsible for access attribute assignment.  This site: 
    8189   * hosts an attribute request form where users can register, agree to terms and be allocated the attribute attributeA to enable them to access datasetA; 
     
    8391 
    8492==== Assumptions ==== 
    85  * Use case for browser based access 
    86  * user is not logged in to NCAR site 
    87  * user doesn't have authorization for datasetA access 
    88  * control to datasetA is governed by an attribute called attributeA. 
     93 * This is a use case for browser based access only 
     94 * The user is not logged in to NCAR site 
     95 * Control to ''datasetA'' is governed by an attribute ''attributeA''. 
     96 * The user is '''not''' registered for access to ''datasetA''. 
    8997 
    9098==== Triggers ==== 
     
    92100 
    93101==== Outcome ==== 
    94 User is granted access rights to secured datasetA data from BADC site. 
     102User is registered for access to secured datasetA data from BADC site. 
    95103 
    96104==== Normal Course ==== 
    97  13. The BADC site redirects the user's browser to the authorization request form hosted at the BADC. 
    98  13. The user completes details, agrees to the terms of a usage policy, submits and awaits a response. 
     105Continuing from point 13) in the last use case: 
     106 1. The Attribute Service returns a response to the PDP that the NCAR user is '''not''' registered for attributeA. 
     107 1. The BADC site redirects the user's browser to the authorization request form hosted at the BADC. 
     108 1. The user completes details, agrees to the terms of a usage policy, submits and awaits a response. 
    99109 1. The details from the form are submitted to the BADC Attribute Service. 
    100  1. The user is approved for access to datasetA.  (This may an immediate decision or it may require submission to an approval panel). 
     110 1. The user is approved for access to datasetA.  (This may be an immediate decision or it may require submission to an approval panel). 
    101111 1. When approved, the Attribute Service creates a user profile for this user containing attributeA. 
    102  1. If approval is immediate, the BADC can redirect the NCAR user to the page for datasetA download. 
    103  1. 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). 
     112 1. If approval is immediate, the BADC site can redirect the NCAR user to the page for datasetA download. 
     113 1. 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). 
    104114 
    105115----