(r13) SsoRFC < IVOA

IVOA Web>SsoRFC (revision 13) (raw view)~~EditAttach~~
---+ Single-Sign-On Profile: Request for Comments

This document will act as *RFC* centre for the [[http://www.ivoa.net/Documents/PR/GWS/SSOAuthMech-20070621.doc][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 TWiki.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)

<br>
---

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 [[RaysDetailSSOComments#Introduction][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 <nop>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 [[RaysDetailSSOComments#7_1_Details_of_digital_signature][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 [[RaysDetailSSOComments#8_2_Certificae_chains][some edits to do this]].  

IVOA.RayPlante - 13 Aug 2007

I agree with all these comments and have made the appropriate edits to the specification documentation. (IVOA.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)

---+++ Bob Hanisch (Data Curation &amp; Preservation IG)

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

---+++ Gerard Lemson (Theory IG)

---+++ Mireille Louys (Data Models WG)

---+++ 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.

---+++ Francois Ochsenbein (VOTable WG)

---+++ Pedro Osuna (VOQL WG)

---+++ Ray Plante (Resource Registry WG)

---+++ Andrea Preite-Martinez (Semantics WG)

I approve the document, although I agree with Bob's comment above.

---+++ Roy Williams (VOEvent WG)

I approve this document.

<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
Topic revision: r13 - 2007-09-10 - MarkAllen
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema