A RESTFul HTTP mapping of the BES WSDL
Dear all, due to the raising popularity of RESTFul interfaces on plain HTTP, we decided to investigate the mapping of the BES WSDL into RESTFul HTTP. For those interested, the result of our work is documented in this technical report: http://www.lnf.infn.it/sis/preprint/detail.php?id=5111 Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40127 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi
Sergio: It looks nice. How do you address security? Ian. On Sep 30, 2008, at 8:17 AM, Sergio Andreozzi wrote:
Dear all,
due to the raising popularity of RESTFul interfaces on plain HTTP, we decided to investigate the mapping of the BES WSDL into RESTFul HTTP.
For those interested, the result of our work is documented in this technical report: http://www.lnf.infn.it/sis/preprint/detail.php?id=5111
Cheers, Sergio
-- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40127 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi -- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
Could you not employ X.509 client/server authentication at the TLS layer? I believe you can access the certificate information when processing the HTTP operations. Just wondering.... -- Chris On 30/9/08 08:09 , "Sergio Andreozzi" <sergio.andreozzi@cnaf.infn.it> wrote:
Dear Ian,
Ian Foster wrote:
Sergio:
It looks nice. How do you address security?
the security aspect is still an open issue that we have not faced yet. So far, we have concentrated our study on the mapping of the operations.
Best regards, Sergio -- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
Christopher Smith wrote:
Could you not employ X.509 client/server authentication at the TLS layer? I believe you can access the certificate information when processing the HTTP operations.
Just wondering....
That sounds like an entirely practical way of doing it to me, especially as there is rather a lot of in-service experience out there with handling authentication and authorization for access to HTTP operations. There might be a few tricky bits of course (notably how to handle telling the client how to authenticate to the server, though in the fallback case of username/password all that stuff exists already) but it still seems quite possible. I like the idea that the interfaces we define are fundamentally independent of how they are interacted with. That has the architectural equivalent of Good Code Smell. :-) Donal.
On Tuesday 30 September 2008 18:42, Donal K. Fellows wrote:
Christopher Smith wrote:
Could you not employ X.509 client/server authentication at the TLS layer? I believe you can access the certificate information when processing the HTTP operations.
Just wondering....
That sounds like an entirely practical way of doing it to me, especially as there is rather a lot of in-service experience out there with handling authentication and authorization for access to HTTP operations. There might be a few tricky bits of course (notably how to handle telling the client how to authenticate to the server, though in the fallback case of username/password all that stuff exists already) but it still seems quite possible.
How about delegation? Will it require additional mapping? Or should it be handled in a separate layer? A.K.
I like the idea that the interfaces we define are fundamentally independent of how they are interacted with. That has the architectural equivalent of Good Code Smell. :-)
Donal. -- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
Aleksandr Konstantinov wrote:
On Tuesday 30 September 2008 18:42, Donal K. Fellows wrote:
Christopher Smith wrote:
Could you not employ X.509 client/server authentication at the TLS layer? I believe you can access the certificate information when processing the HTTP operations.
Just wondering....
That sounds like an entirely practical way of doing it to me, especially as there is rather a lot of in-service experience out there with handling authentication and authorization for access to HTTP operations. There might be a few tricky bits of course (notably how to handle telling the client how to authenticate to the server, though in the fallback case of username/password all that stuff exists already) but it still seems quite possible.
How about delegation? Will it require additional mapping? Or should it be handled in a separate layer?
I think from a standpoint of the Grid embedded into the Web, it is interesting to look at what the Web community proposes in this area - for example, OpenID for 1st party, and OAuth for 3rd party (including delegation). (?) Roger
A.K.
I like the idea that the interfaces we define are fundamentally independent of how they are interacted with. That has the architectural equivalent of Good Code Smell. :-)
Donal. -- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- Dr. Roger Menday Juelich Supercomputing Centre Institute for Advanced Simulation Forschungszentrum Juelich GmbH 52425 Juelich, Germany Email: r.menday@fz-juelich.de Skype: yadnem Phone: +49 2461 611588 http://www.fz-juelich.de/jsc JSC is the coordinator of the John von Neumann Institute for Computing (NIC) and member of the Gauss Centre for Supercomputing (GCS) ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------
participants (6)
-
Aleksandr Konstantinov -
Christopher Smith -
Donal K. Fellows -
Ian Foster -
Roger Menday -
Sergio Andreozzi