Re: do component managers need to authenticate researchers?

Another implication (and potential challenge) of the alternative approach is that the AM has to maintain the state of credentials. This appears to be a more stateful approach compared with the orignial one, and this may also have implications for the allowable time interval between a research getting his resource-access-credential and actually using the resource.

Of course, there may be constraints at switches that make the suggested alternative approach more attractive than the original one. It would be interesting to discuss such constriants and examine their implications for the GENI architecture.

Hongwei


Aaron Falk wrote:

Several folks from Cluster B and the GPO met a few weeks ago to discuss
how to network switches would be integrated into this cluster.  Guido
Appenzeller, from the Enterprise GENI project. had some thoughts on
changes to the conceptual design's authentication approach that are
worth repeating here and possibly discussing further.  (Slides, minutes,
other reading can be found at [1].  In particular, see slides 41-50 of [2].)

To illustrate the issue, let's take the case of a researcher who wants
to contact an aggregate manager (AM) to make a resource reservation. 
Notionally, a researcher would send this request and include signed
credentials that would give him authority to perform this task.  The
aggregate manager would verify the credentials were signed by an entity
the AM trusted. 

The proposal on the table is for a simpler approach.  The AM maintains
an SSL connection to the clearinghouse (CH).  Researcher credentials are
sent to the AM by way of the clearinghouse and the validates the
credentials before forwarding the request to the AM.  This removes
burden of validating the credentials from the AM at the expense of
forcing requests to pass through the clearinghouse. 

There is a fundamental change here in the need for a GENI-wide PKI is
removed and the crypto functions in the AM are reduced to maintaining an
SSL connection.  Also, the aggregate manager's control plane API becomes
much simpler, e.g., roles and credentials added many calls and options
to the PlanetLab Slice-Federated Architecture.  However, this changes
the message flow in GENI in a significant way, making the clearinghouse
a waypoint for control plane communications between researches and AMs.

>From a near-term, implementation perspective, this seems like a
advantageous change.  A complex, not-well-understood function
(researcher credential authentication) has been moved out of the
development path of aggregates and their managers.  However, I'd like to
understand what the costs are of this design.

Thanks,

--aaron

ps. Cluster B is going to add a prototype interface of this design.  In
fact, a PLC geniwrapper initial patch is already available at [3].

pps.  There was also an interesting discussion of the benefits of
SOAP/XSDL as compared to Pyton/XML-RPC and the patch above represents an
XSDL implementation of a control plane API.

[1] http://groups.geni.net/geni/wiki/ClusterB
[2]
http://groups.geni.net/geni/attachment/wiki/ClusterB/Enterprise%20Geni.pdf
[3] http://www.openflowswitch.org/wk/index.php/GENILight


  

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg