Single-Sign-On Profile: Request for Comments

This document will act as RFC centre for the IVOA Single-Sign-On Profile: Authentication Mechanisms Proposed Recommendation V1.00

Review period: 17 July 2007 to 31 August 2007

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussions about any of the comments or responses should be conducted on the GWS mailing list, grid@ivoa.net.

Implementation details

The IVOA SSO Profile approves four mechanisms:

• No authentication
• Digital signature of messages
• TLS (Transport Layer Security) with client certificates
• TLS with passwords

The required components to support this profile are:

• Client software for digital signature for SOAP
• Server software for digital signature for SOAP
• Client software for HTTPS with proxy certificates
• Server software for HTTPS with proxy certificates

The following implementations for each component are known:

• Digital signature for SOAP (client):
  • AstroGrid security facade + Astro Runtime
  • Caltech VOSpace secure client (using Axis WSS4J 1.5.0)

• Digital signature for SOAP (service):
  • AstroGrid security facade + CEA app-server
  • Caltech VOSpace server

• HTTPS + RFC3820 (proxy certificates) components (client):
  • curl
  • htcp (from GridSite)
  • globus-url-copy (from Globus Toolkit)
  • Matthew Graham's HTTPS + RFC3820 Java code

• HTTPS + RFC3820 components (service):
  • Tomcat + GList trust-manager
  • Tomcat + AstroGrid trust-manager
  • Apache httpd + GridSite module
  • Jetty + Brun Harbulot's trust manager

Comments

• First sample comment (by MarSierra): ...
  • Response (by authorname): ...

• This is kind of an unusual document, in that it is not a definition of a standard interface but rather more a statement of principle. Perhaps it is not even necessary to have this as a REC. But if the GWS WG prefers it this way, ok. (BobHanisch)
  • It's a description of the various mechanisms that the IVOA sanctions for use in security infrastructures and how these should be used: for example, HTTPS has to support proxy certificates which is not a common use case and so requires a particular subset of the available libraries to be used. This is one reason why we have been very specific that there are multiple implementations available that support each of the technical aspects presented here. If there is another way to get IVOA approval for an IVOA policy then please let us know what it is.(MatthewGraham)

RayPlante - 13 Aug 2007

I summarize my comments here; however, consult RaysDetailSSOComments for details, including some suggested text.

• I would recommend a statement acknowledging NSF in the acknowledgements section for the NVO contributions. I would encourage similar statements for other projects as appropriate. (See RaysDetailSSOComments for suggested text.)

• All abbreviations should be spelled out and defined before they are used, even the obvious ones. I recommend the obvious ones be defined in a special Preface section called "Definitions" so as not to interrupt the flow of the main text.

• This document is likely to be a confusing read because (1) it talks about details that are explained in other documents, and (2) explanatory comments about these details--i.e. the "Comments" sections--appear after the introduction of these details. One way to alleviate this problem might be to add some cautionary statements to the Introduction that explains this structure.

more coming.

RayPlante - 13 Aug 2007