perfsonar development work

[Nicolas Simar <>]

I think is is also relevant for you.

Cheers,
Nicolas

-------- Original Message --------
Subject: [GN2-JRA1] JRAs and SAs requir. for user's attributes in GIdP
Date: Tue, 28 Nov 2006 17:16:59 +0000
From: Maurizio Molina 
<>
To: GEANT2 ID provider <>, 
GN2-JRA1-DANTE-list <>,	GN2/JRA2 Mailing List 
<>, , 	Michael Enrico 
<>,	JRA5 Members <>, 


Hi,
I summarise the feedback on attribute requirements for GIdP's registered
users received from
- SA3 (AMPS)
- JRA1 (perfSONAR)
- JRA3
- SA3 (cNIS)
- JRA4

SA3 (AMPS) and JRA1 (perfSONAR) provided the more exhaustive response,
and are in many aspects similar. So, I consider them together. Also,
other activities may want to further see if this actually accomodates
their needs.

SA3 (AMPS) and JRA1 (perfSONAR)
============================
They require 5 "Cathegories" of attributes

1) Attributes relative to the "role" of the user. I.e. what the user
*does* within an organization.
There are some slight differences between SA3 and JRA1:
- JRA1 attempted to define a vocabulary (allowed values) for that: NOC,
PERT, NREN-non-techn-staff, End User (ordinary), Security User, Network
Researcher.
- SA3 did not define a vocabulary, but just gave examples
- JRA1: attribute must be multiple valued
- SA3: attribute is single valued
- Both:  the attribute can have has an associated "hierarchy": E.g.
urn:geant:edugain:component:perfsonar:user:gr.ntua. SA3 wants to do a
"longest prefix match" AuthZ. For example, if group is
urn:geant:edugain:component:perfsonar:user:gr.ntua,  this user may get
only generic priviledges, but if group is
urn:geant:edugain:component:perfsonar:user:gr:ntua:noc
this user may get higher priviledges, and if it is
urn:geant:edugain:component:perfsonar:user:gr:ntua:noc:head_of_noc,
even higher.
- Both: the attribute can be used for AuthZ

2) Attributes relative to the "project" or "scope" the user belongs to.
This information is "orthogonal" to the previous one (and posibly
overrides - or complements it for AutZ purposes). It is likely to be
more short-time-lived than the previous one.
- JRA1: examples are L3 projects, PiP project, L2 projects
- SA3: examples are default, egee, gn2
- Both: the attribute must be multiple valued
- Both: the attribute is non-hierarchical, although JRA1 thinks it *may*
be useful to extend it with more specific information like
"project:role_within_the_project:sub_role_within_the project, etc...
Harmonising the role and sub-role definition across projects is of
course too complicated, but an application may decide to take its AuthZ
decision considering this attribute just up to the "depth" it is able to
understand.
- Both: the attribute can be used for AuthZ

3)  Attributes relative to the "network connectivity", or "network
domain" of the user, which is "normally" (but nor always)
NREN:<end_institution>.
- Both: the attribute has a  hierarchy associated with it
- Both: th attribute is single-valued
- Both: the attribute can be used for AuthZ

4) Attributes relative to who the user *is* and how she/he/it can be
contacted. Thus: Full name, e-mail, phone, work-address, etc. Thiese
attribute is not used for AuthZ, but may be logged for other purposes
(e.g. to trace back abuse or misuse, etc.). AuthZ may be denied if these
attributes are not transferred for privacy restrictions, or if there is
not at least the possibility to obtain a  at least an opaque, persistent
unique ID that the resource can use as a key for obtaining (possibly
off-line) the full information from the IDP in case of abuse.

5) Attributes relative to the login of the user. Looks like a "nickname"
or mnemonic userid. Also used for logging purposes rather than AuthZ

SA3 (cNIS):
========
Discussion just started, but it looks like that they will make use of
the eduGAIN Automated Client profile (when the resource is the cNIS
itself, being accessed by other elements) or the eduGAIN SSO profile
(when the resource is is teh administrative interface of the cNIS itself).
So far, they don't see the need of doing AuthZ on any attribute at all
(i.e. they'd be happy to to base authZ on the CID of the certificate).
More feedback promised by the 10th of Nov.

JRA2:
=====
no answer

JRA3:
=====
Basically no requirement (except a unique User ID), since they say they
plan  to duplicate info about users across all the possible  Systems
(one per domain...) and perform authZ locally....
- Discussion is however ongoing.

JRA4:
=====
Extended explanation can be found here, but basically no requirements
seem to be added on the top of  JRA1's or SA3's ones:
http://wiki.geant2.net/bin/view/SA3/MichaelOnJRA4
Basically, there's the need to distiguish between three types of users:
- project users (e.g. a perfSONAR client process owned by someone
associated with a (uniquely named) project. Individual users may be
associated with more than one project.
- domain (management) users (e.g. a perfSONAR client process owned by
NOC/operational staff within a particular domain)
- super (management) users (e.g. a perfSONAR client process owned by
E2ECU operational staff)
Discussion is ongoing, and further feedback may come.

This is my understanding. Activities' participants may want to correct me.
Thanks to who sent their feedback or worked for this to happen....
Regards,
Maurizio



--
Nicolas
______________________________________________________________________

Nicolas Simar
Network Engineer

DANTE - www.dante.net

Tel - BE: +32 (0) 4 366 93 49
Tel - UK: +44 (0)1223 371 300
Mobile: +44 (0) 7740 176 883

City House, 126-130 Hills Road
Cambridge CB2 1PQ
UK
_____________________________________________________________________