perfsonar-dev - AA - draft notes of the perfSONAR-eduGAIN meeting
Subject: perfsonar development work
List archive
- From: Maurizio Molina <>
- To: Perfsonar Development List <>
- Subject: AA - draft notes of the perfSONAR-eduGAIN meeting
- Date: Tue, 16 Jan 2007 10:51:17 +0000
Please review and make your comments.
Thanks,
Maurizio
Meeting was held in Cambridge, on the 9th of Jan 2007.
Participants:
Diego, Maurizio, Stephan, Jochem, Andreas, David, Loukik, Jeff, Eric
MM: did I forget anybody?
1) Diego presented (on behalf of Candido) a detailed breakdown
(attached) of the actions that the perfSONAR Resources (pSR) and the AS
need to do for implementing the high level design specified by DJ1.2.4.
For the perfSONAR resource, it is assumed that the resource has already
a "security token".
2) perfSONAR needs to come with a similar breakdown to describe how to
reach this point, i.e. how the security token is extracted from the
client request.
2.1) it was noted that this is sort of trivial if the client has a TLS
connection with the pSR (Tomcat will do the decoding for you...)
2.2) in case of usage of WS security, it should be described how the
security token is encoded in the SOAP message (header or body, perfSONAR
has yet to decide...).
At the end, the initial part of pSR 's operations needs to be
implemented in a function called by the pSR each time a request is
received by a client. This function will "initialize" all the data
needed to further process this request and forward it to the AS.
3) perfSONAR also need to come with a proposal about how to encode the
type of action the client is requesting.
3.1) it was noted that SAML 1.1. has an element called "action" that can
be used for that
3.2) another possibility is to encode it as a urn: example:
ps://measure_bandwidth?freq=1024&proto=UDP
(MM: I don't remember if the above 3.1 and 3.2 are alternative methods,
neiter if we are speaking about the cli to pSR request, or the one from
the pSR to the AS, or both).
4) it was decided that the identity of the resource need not to be
encoded in the request of the pSR to the AS. Rather, the following
methods could be used: IP addresses check, shared secret between the pSR
and AS (MM: how???), certificates (if TLS from pSR to AS is used).
5) for the CLI interaction with the MDS, it was noted that the MDS has a
simple rest interface. It means: you make a request and get back a SAML
assertion.
6) it was clarifuied that the following perfSONAR clients follow in the
following cases:
a) CNM: Automated Client
b) perfSONAR UI: UbC
c) visualperfSONAR: Web containEr
perfSONAR is going to specify and develop the needed AA function for
them in this temporal order: a) b) c)
- AA - draft notes of the perfSONAR-eduGAIN meeting, Maurizio Molina, 01/16/2007
Archive powered by MHonArc 2.6.16.