perfsonar development work

[Nicolas Simar <>]

Hi Candido,

Cándido Rodríguez Montes wrote:
> Hi Nicolas,
>
> El 05/09/2007, a las 9:55, Nicolas Simar escribió:
>
> > Hi Candido,
> >
> > Can you summarise the status of the work and the next steps for the 
> > following:
> >
> > - the three modules for visualisation
> > -- UbC - ?
>
>
> We have the authn library for this case and it's integrated with the 
> SASL-CA server and the eduGAIN metadata service (MDS). The library asks 
> MDS for the available federations in eduGAIN and also it can get a valid 
> X.509 certificate from a SASL CA server. But, before it can be used, the 
> following problems have to be resolved:
> + Contact information of the SASL CA server of a federation have to be 
> included in the MDS. This has been requested to JRA5 guys because it 
> hasn't beed specified how to include the information of this kind of 
> software in the MDS.

For when would you need this specific piece of work to be done?

> + Certificates issued by SASL CA have a bug and I'm waiting a new 
> release from Derek Morr.
> Until this problem would be resolved, I'm writting the documentation and 
> tutorials in the wiki. I'll advise when it'd be available!
>
> > -- AC - done, not tested with pS web-service
>
>
> Is there any AC for the SSH Telnet MP?

Please liaise with David Schmitz.

> > -- WE - done, not tested with pS web-service
>
>
> Is there any WE for the SSH Telnet MP?

I don't know.

> Anyway, as implementing the authentication process is so easy (I hope :) 
> ) I think we can choose another pS web-service contacted by a AC or a WE 
> so we can test that case.
>
> > - the Auth service - done, one instance deployed for test
> > -- Seeking to interface with the GIdP
>
>
> A full connection with the GIdP will be done when:
> - GIdP would be available in the MDS (I'll send an email to Maurizio for 
> this).
> - SASL CA server would be deployed for the GIdP (Waiting for the new 
> version of SASL-CA)

Keep me poste about the progress...

> > - the component for the java services - done
> > -- Test with Auth service successful
>
>
> Ok
>
> > - the java code for the perfsonar web-services (java)
>
> There is a test and you can run it executing 'ant -f 
> build.as run-psr-x509-service' in the ant directory.
>
> Also, there is another task: moving all authn classes to the new svn 
> structure. I hope it will be done by Friday.

OK.

> > 1) When do you think we can start asking the other perfsonar 
> > developers to include the Auth component within their service?
> > 1.1) Do you feel confident that even if no test have been done between 
> > a client and a perfSONAR web-service, we can proceed ahead?
>
>
> Well, after the Sitjn's work, we can think that the integration of the 
> authn in a perfSONAR web-service (pSR) is easy, so, I think we should 
> start with clients. Why? Because if clients implement the authn process, 
> it doesn't matter if the pSR have implemented too. But, in the other 
> case, if pSRs implement the authn process and clients not, pSRs will 
> send them an authentication error.
> So, for the pSR that we want to add the authn process, which clients 
> connect them? only perfSONAR UI (which is in the UbC case)?
> Anyway, I think we can proceed ahead. Of course, we can find some bugs, 
> but it will be fixed as soon as possible.

OK. If a bug is found, would that mean that all the developers of the 
services that have integrated AA will have to fix it, or if you fix it, 
it will waterfall on all the other services?

> > 2) The message for the non java web-services having been defined, we 
> > can  start asking the non java web-services developer to integrate the 
> > tool.
>
>
> Also, if there are perl clients which connect them, we should know it, 
> so we can help their developers for integrating them in the authn process.
>
> > 3) About authorization, Anand has done the very good suggestion to use 
> > the following rule: anybody who is authenticated can access the service.
> > 3.1) Can we limit this to only the accounts on the GIdP? Or would 
> > anybody who has an edugain account be able to access the information?
>
>
> Well, all X.509 certificates and SAML assertions include the component 
> ID (cID) of the client/user. It has the information about the name of 
> its federation and its unique ID. We can filter the authorization by any 
> cID, cIDs from an specific federation or by specific federation and the 
> ID of the client/user.
> So, we can define a basic "policy" for the authorization right now.

I was more thinking for the time being, where we only have 
Authentication possibility (or is the solution you suggest working in 
the "currently" developped situation (i.e. without Autz service).

> > It seems to me that we are still on target to have Auth integrated for 
> > end of October.
>
> I think so :)

Excellent!

Cheers,
Nicolas

> Regards
>
> > Thanks a lot.
> >
> > Cheers,
> > --
> > Nicolas
> > ______________________________________________________________________
> >
> > Nicolas Simar
> > Network Engineer
> >
> > DANTE - www.dante.net <http://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
> > _____________________________________________________________________
>
> --
> Cándido Rodríguez Montes E-mail:  
> <mailto:>
> Red.ES/RedIRIS Tel:+34 955 05 66 13
> Edificio CICA
> Avenida Reina Mercedes, s/n
> 41012 Sevilla
> SPAIN

--
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
_____________________________________________________________________