IVOA Web>SsoRFC (2007-09-12, GerardLemson)

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. I also recommend that we make sure that at least one explanatory statement be provided for each detail referenced from an external spec--particularly jargon.

Section 2.2: There is a font issue on the URL inside the accessURL element.

Section 3.1: Change "Interfaces of type WebService..." to "Services that are registered with a VO registry as having a WebService type interface [VOResource]...."

Section 5.1: I strongly recommend that the URIs that identify a security method use the form, ivo://ivoa.net/sso#method-name. As the authors know, every IVOA Identifier must resolve to a separate resource description. By using the pound delimiter, all of the method names can be defined within a single resource description.

Section 5.1: ...Thus, change "ivo://ivoa.net/sso/tls-with-client-certificate" to "ivo://ivoa.net/sso#tls-with-client-certificate".

Section 6.1: Change "ivo://ivoa.net/sso/tls-with-password" to "ivo://ivoa.net/sso#tls-with-password".

Section 7.1: Some indication that the elements referred to in the second paragraph are defined in WS-Security spec. I recommend including the section number of that document.

Section 7.1: Follow the term "trust anchor" with a reference to a document that defines this term.

Section 7.1: Change "ivo://ivoa.net/sso/soap-digital-signature" to "ivo://ivoa.net/sso#soap-digital-signature".

Section 7.2: Section 8.2 gives a nice explanation of what is meant by a "trust anchor". However, as this i term is first introduced in section 7.1, it might be nice to either (1) provide brief explanatory remark here in section 7.2, or (2) provide a forward reference to section 8.2. I suggest some text to insert.

Section 7.2: Please also add a comment explaining what a "suitable SecurityTokenReference " would be.

Section 8.1: Second paragraph: Follow the term "trust anchor" with a reference to a document that defines this term.

Section 8.2: The NVO certificate issuing services are capable of issuing short-term EECs. The rationale is that this opens up its use by a wider set of applications because it does not require the application to support proxy certificate chains [RFC3820]. That way only those applications that need to support delegation need to support this extra standard. As a result, I would recommend softening the language describing the role of EECs and proxies. I recommend some edits to do this.

RayPlante - 13 Aug 2007

I agree with all these comments and have made the appropriate edits to the specification documentation. (MatthewGraham - 06 Sep 2007)

Comments by TCG

Chairs should add their comments under their name.

Mark Allen (Applications WG)

I approve

Christophe Arviset (TCG vice Chair)

I approve this document.

Bob Hanisch (Data Curation & Preservation IG)

Matthew responded to the original concern I raised, and I have no others. I approve.

Gerard Lemson (Theory IG)

I approve.

Mireille Louys (Data Models WG)

I approve the document because I have no objections against it, neither towards the achieved work it represents, I am just too far from this topic. I wish IVOA implementers would complete it in the future with a "Lessons learned" section in order to evaluate the pros and cons of the various solutions exposed here.

Keith Noddle (DAL WG)

I approve this document. Although it is different from many of the other standards, it is vital we stake out some ground and get the ball rolling. I hope moving this document to V1.0 status is the spur needed to get some substantial work started.