SSO v2.0 Proposed Recommendation: Request for Comments

Public discussion page for the IVOA SSO 2.0 Proposed Recommendation.

The latest version of the SSO Specification can be found at:

• PR-SSOAuthMech-2.0-20170411.pdf

Comments from the IVOA Community and TCG members during RFC period: 2015-11-01 - 2015-12-13

Comment by Pierre Fernique

1. Are there authenticated services already described in the VO registry ? and if yes, is it already in use ? Can we considered it as a reference implementation ? And in fact, do we have reference implementations ?
2. Author list and editor lists seems to not follow the current usage of IVOA. It is a little bit strange to have all the Grid and Web service group as authors, and 3 editors. Maybe it opens the question concerning the method to keep knowledge of successive editors.
3. I wonder if all complementary sections (short introduction to each authentication method) are really relevant in an IVOA standard. I would suggest to put all normative points in a dedicated section and move all explanation of existing authoritative methods in an general non normative section, or as an appendix.
4. The structuration of section 3 could be modified for avoiding the section 3.1 alone item.
5. Appendix A must have a short introduction to explain what is this long XML schema. The title "VOResource SecurityMethod extract" is definitively not clear.
6. must, may, shall... should be in uppercase in normative sections.

Typos:

• p1: Andreé => André
• p4: user?s => users
• p4: service?s => service
• p4: Is => If a service
• p6: as having a em Web => ?
• p7: table 1 label strangely folded

-- PierreFernique - 2015-11-01

Reply to Pierre Comments

Thanks Pierre for your comments and suggestions

1. Question (1): According to my query to the Registry there are some services that are using the “security methods”, in fact this is an update of an existing recommendation and we are not modifying the resource schema. They are mainly VOSpace implementations (one of them is the Canadian one). However, I am not sure that this kind of document requires a “reference implementation”, in fact this document is a profile against existing security standards, we are proposing a way standards apply in the framework of the VO. This means that we want to identify a way services requiring authentication advertise that clients and we want identify and eventually rank a sub set of the authentication protocols available.
2. I used the format of the previous SSO document, however I agree with you so now I provide a list of Authors and one Editor
3. We try to keep the same format as the old version, and being a profile against existing security standards, we think it is important (especially for application developers) to have also non normative sections. To be consistent with the original document I would rather prefer to keep this format.
4. I modify the document according yo your suggestion
5. The appendix is just an extract of the VOResource description. As requested by the GWS, we include a copy of the XML schema for the SecurityMethod element. I change the Appendix name and I add also a short introduction, however I think that it could also be removed.
   

Comments from MarkTaylor

I don't have a good enough understanding of security to assess the substance of this document, but I have some editorial comments.

1. Sec 1: "... to another service This ..." -> "... to another service. This ..."
2. Sec 2.1: "... this element distinguished ..." -> "... this element distinguishes ..."
3. Sec 2.2: There are problems with the XML snippets included here. The <interface> start tag in both cases assigns an attribute with the name xmlns:vs: - I'm pretty sure the trailing colon there should be removed. Also, the attribute assignments are quoted with repeated single quotes e.g. xsi:type=''vs:ParamHTTP'' - that looks a bit wrong in the PDF but is definitely wrong in the HTML. Quote using single quotes (or single-character double quotes) instead.
4. Sec 2.2: "The order identify the priority ..." -> "The order identifies the priority ..."
5. Sec 2.2: "... SAML, than cookies ..." -> "... SAML, then cookies ..."
6. Sec 3.1: "... combination of the them" -> "... combination of them." ?
7. Table 1: This table lists IVOA Identifiers defined as securityMethod values. These identifiers are in some cases referenced in the mechanism-specific subsections later in the text, but not others, e.g. sec 7.1 says: "Interfaces using this mechanism shall be be registered with the security method ivo://ivoa.net/sso#tls-with-password ." , but there is no corresponding note in the subsections describing cookies, OAuth, SAML or OpenID. Similar notes should be added to the relevant subsections for consistency and clarity.
8. Table 1: The HTTP Basic Authentication securityMethod value in this table is missing a colon ( http//www..." ).
9. Table 1: Where does the HTTP Basic Auth URI come from? There's no requirement that these URIs are dereferenceable, but using the form http://www.w3.org/Protocols/HTTP/1.0/spec/html#BasicAA which has a different form from the others, looks like it would make sense if that URL was dereferenceable, but it's not. There might be a good answer to this, but I'm interested to know what it is.
10. Sec 9.2: "IdP" and "IDP" are both used, are these the same thing?
11. Sec 9.2: "SAML2.0 allow also to service discovery mechanisms" - I don't understand what this means.
12. Appendix A: I can reply as I did above for Pierre question. The appendix is just an extract of the VOResource description. As requested by the GWS, we include a copy of the XML schema for the SecurityMethod element. I change the Appendix name and I add also a short introduction, however I think that it could also be removed.

-- MarkTaylor - 2015-11-12

Reply to Mark questions

Thanks for your comments and suggestions. I correct all the typos following your suggestions.

3. Thanks, that was a typo introduced converting from word to latex.

7. I modify the text to be consistent.

9. Sorry, the URL is actually dereferenceable but there was a typo. The correct url is https://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA

12.

Appendix A: Like Pierre, I don't understand what this XML is doing here. Also, the top-level xs:schema element contains the attribute version="1.02" - what's that the version of?

As I explained to Pierre that was a request from GWS WG (see the above answer).

Comments from MarkusDemleitner

In general, I have to admit I am not altogether sure what the function of this standard is -- is it intended to just list authentication methods that people should use in the VO and give them names? If so, I guess much of the prose doesn't serve much purpose, and perhaps the standard would benefit from removing them as the reader wouldn't be led to expect more than such references.

If, on the other hand, the objective is to provide guidance on how to implement services requiring authentication in a VO context, I believe much more practical advice was in order. That, in particular, concerns the mechanisms involving third parties, i.e., SAML and OAuth, and to some degree TLS (insofar as certificates really only make sense with some PKI). Natural questions one might have for those are: Are there IdPs or ASes in use by VO projects? Perhaps even operated by them? What policies do those have? Are ways for discovering them being planned? Can I, as an implementor, freeride on existing authentication infrastructures, and if so, which? Such information could be given in non-normative sections, such that it wouldn't hurt if the infrastructures were taken down.

Another natural question people might expect to see answered if there's "Commentary" in the first place is if, at the time of writing, there was already client support for a given protocol in some VO clients.

Conversely, client authors are probably overwhelmed by the sheer number of protocols "approved" here -- are they expected to implement all of them? If not (and I sure hope there is no such expectation), is there any rational way to decide? Perhaps the document could say something like "if in doubt, implement this and this, and if you're still not satisified, our next choice would be this". This would also give some indication to service implementors which mechanism to choose if they're free to choose.

More concrete issues:

For reasons of nicely formatted references, I'd really prefer if there were actual author names given in the metadata.

p. 6 "Services that are registered with a IVOA registry as having a em WebService type interface..." Apart from the spurious em, I believe this sentence should go in accordance with the change log ("...remove all references to SOAP..."). The WebService interface type in VOResource is annotated with "A Web Service that is describable by a WSDL document", which I take to mean "A SOAP interface" (I am fairly sure that was the intention, anyway).

p. 8 "particular attention" -> ? (particular care? but care for what?)

p. 11 "OAuth is related" -> ?

Does Appendix A actually help? My feeling is that a chapter-exact reference into VOResource would do at least as well. Or perhaps just include generated documentation using the new ivoatex/schemadoc.xslt mechanism (cf. ivoatexDoc in volute trunk).

p. 13 "...methods ad relative..." -> ?

-- MarkusDemleitner - 2015-12-10

Reply to Marcus

Thanks Markus for your suggestions

The idea of this document is to provide a reference to existing standards for authentication that can be used when we require access to private “data”. Actually this SecutiryMethod is used by VOSpace services, but it is not limited to it (see. Eg. CADC services). So the VOSpace clients are using and implementing some of those protocols. As you said we can include in the Commentary if there is an implementation, I am not sure that this document is the right place to do that.

I do not think that the way the authentication policies are implemented by a project (even a VO project) should be discussed in this document, it is a decision to make at a project level, even if we want to operate a IdP or just a SP, depends on project (data center) decisions. Than, the policies in fact do not affect the protocol, the once a service tells a client that it requires tls-with-password, the client should be able to start a TLS communication and send a username/password. Both of these actions are fully documented in the rfc we cite in the document. The SecurityMethod is a way to advertise the client (or other services) and it is already in place in the Registry.

I agree that “ranking” the SecurityMethods could be useful for someone needs to implement a new service, so we add a final commentary with some suggestions.

Comments from TCG members during the TCG Review Period: 2015-12-01 - 2016-01-15

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard.

IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.

TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )

Applications Working Group ( _Pierre Fernique, Tom Donaldson )

There are still few typos:

- author list
- §2.2 "securityMethod" (strange font)
- §12 "user?s", "user?given", "don?t" => quotes wrongly replaced by question mark character

Apart from these details, I approve this new release of SSO PR.

-- PierreFernique - 2016-10-15

I also approve this new release.

-- TomDonaldson - 2016-10-21

Answer: Dear Tom and Pierre, thanks fot you suggestions, we correct those typos in the new doc release.

Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )

Apart from some typos (author names Brian Majour and Andrè Schaaff fro example or the recurrent "Interfaces using this mechanism SHALL be be registered with the security method ....." ....) and the use of VODataservice-1.0 instead of last Rec version VODataservice-1.1 in the example (page 5) we see no issues to have this specification becoming a REC.

FrancoisBonnarel MarcoMolinaro - 2016-10-14

We definitely validate this cleaned up version.

Remaining little typos: Ackowledment "Europena commission" 4.2 Commentary: "transport-" no need for the hyphen 6.2 Commentary ; suppress the coma after "both" in "both, the client and the service" 9.2 Commentary : "the user authenticates" 12 Conclusions: in the sentence "Local SSO is managed ...." I think a period or a "while" should be better after TLS with passwords. "The choice of the authentication to use ...." "offer resources to a large community" or "offer resources to large communities"

Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )

I can't speak too much to the content itself. This topic is outside my expericence, but it seems like a good summary of the various mechanisms which have been reviewed by the community and what the expectations are when being used within the community. If that is the intent, then yea!. With these addressed, I would be comfortable approving the document.

Here are my comments/impressions.. mostly typo-s, some of which have already been mentioned by others.

These are on the 2016-05-01 document.

Front page:

I'm not sure if we have a convention for 'Previous versions', but it looks odd to have WD and PR versions of V1.0 in the list, and not the WD of V2.0. I would expect to see the V1.0 REC, plus maybe the earlier drafts of the V2.0 listed.

"Brian Majour" => Brian Major

Acknowledgements: "working-group of IVOA" => "working-group of the IVOA"

S2.1: "Is a service does not provide" => "If a service does not provide"

S2.2: "More than one security Method can be specificed" .. format of "s" in security is different than the rest.

S2.2: "and finally if the other are not available" => "and finally, if the others are not available,"

S3.0: It is not clear to me what the author list/reference on pg 6 is associated with. I don't see a document title or tag (like, for example, RFC7235)

S3.0: Table1 caption is wrapped oddly

S7.1: "should be used with particular attention." ... to what? If there is a concern about using the HTTP basic authentication, it should be made clear.

S9.2: "In this way" ==> the rest is cut off in PDF as well.

S12: "a list of existing security standards. to implement" ==> remove '.'

S12: This section has several apostrophy-s showing as '?' (eg: user?s)

S12: "need to store and manage credential." => should be "credentials."

S12: "More complex projects/services that needs to offer" => should be "need"

Appendix B: "security methods ad relative discussion sessions:" => should be "and relative discussion sections:"

References: The reference for "Hardt, D (2012)". Title has "RFC 6742" but the text and URL indicate this to be "RFC 6749"

-- MarkCresitelloDittmar - 2016-09-27

One other thing.. I'm not sure what the "implementation" requirements are for this document, but this page should have a section with statement regarding the impelementations.

-- MarkCresitelloDittmar - 2016-09-28

Answer:Dear Mark, we correct all the typos in the document. For what reagards "implementations" I am not sure I understand your question. If it regards the "reference implementations", this standard is already implemented by some services (mainly VOSpaces) and it is possible to query the Registry to find all of them, however this document is providing “profiles” against existing standards, so as we discussed in the GWS we do not think we need any “reference Implementation”. If you are referring to how services shoud implement this standard, we discuss in the GWS-WG that the most efficent approach is: if a service requireres authentication it must publish the "security method", if a service does not require authentication, no security method should be specified, we rephases section 2.1 to clarify this point.

Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )

• There are some comments in the public discussion and the TCG section that need to be addressed.
• I don't think I (Brian) should be listed as first author... the original authors should probably be listed before me.
• I would just like to remind people that the most important part of this document are the URIs used to identify the security methods. These are the elements that will be read programmatically from the interface definitions from the capability documents and registry entries.

With the above points addressed I approve this document.

-- BrianMajor - 2016-10-18

Registry Working Group ( _Markus Demleitner, Theresa Dower )

In addition to Markus' prior comments:

9.2: I'd like to see the revised text with response to Mark Taylor's comments before signing off. At least in the HTML version, the last paragraph is cut off completely. And while I've worked with SAML enough to kind of understand "SAML2.0 protocol allows also to implement authentication service discovery mechanisms", it still could be a bit more clear.

10.2 I'm more confused by the wording in "OAuth is related to delegate credential from an application to another."

Typos:

7.1: User-name vs user name elsewhere

2.1: that service's resource (add apostrophe)

B.1: new security methods and relative discussion sections ("and", "sections")

-- TheresaDower - 2016-09-21

ANSWER: Dear Theresa, thanks for you comments, we correct all the typos in the doc, hopefully. We also update section 9.2 and 10.2 following yous suggestions.

I am satisfied with the section 9.2 and 10.2 updates, and approve of the document.

-- TheresaDower - 2017-04-11

Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )

p3 Acknowledgement : seems out of date, some authors changed affectations. Canvar and the Canadian VO are not mentionned, INAF or other Italian science concil not mentionned either. Was it forgotten?

Semantics WG has no overlaps in terms of standards with this specification, and as a consequence, I leave the decision for approval to my TCG colleagues.

-- MireilleLouys - 2017-03-30

Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )

Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )

Data Curation & Preservation Interest Group ( Françoise Genova )

Operations Interest Group ( _Tom McGlynn, Mark Taylor )

From the perspective of the OIG is would be desirable if there was some mention of how one might validate the various sign-on mechanisms. Since these are all non-IVOA standards one might hope that such facilities have been built.

• The technologies and protocols mentioned in this document are all quite mature. They typically have well tested and used clients (such as wget, curl, browsers) that one could use to validate their use. (-- BrianMajor - 2017-01-17)
• To complete Brian answer, each standard has a different validation method, that is specified in the standard reference document. For SAML there are tools to validate the SAML response that works the same way of the HTML5 validation on line services (e.g. https://www.samltool.com/validate_response.php). Openssl x509 certificate display and signing utility and in particular openssl s_client command can be used to validate an TLS (whit password and with certificates).

More generally, as far as I can understand this document the content could be more clearly summarized in a single table with three columns: A label for the allowed sign-oon mechanism, the standard associated with that label, and the IVOID to be used to identify that approach. If such a table could be added (perhaps as an appendix), I believe it would be extremely useful.

• Tom, I'm not sure if the table was there when you made these comments, but it is there now. Thanks for the idea. (-- BrianMajor - 2017-01-24)
• To make it more visible we add a specific section for it, thnaks again Tom.

I am unclear as to the role this standard plays in the IVOA. It does not seem to discuss or reference any mechanism by which mulitople services would be accessible. I.e., different services can use different sign on mechanisms and there appears to be no mention of a broker that ties such services together.

• You are correct that this document does not explain how the authentication mechanism is determined for services. This, however, is explained in VOResource: The interface records returned by the registry contains 'securityMethod' elements identify the supported auth mechanisms. This is touched on in section 2.2. (-- BrianMajor - 2017-01-17)
• For what regards SSO proxies (or brokers), they are out of the scope of this document, however I think that they represent an hot topic to discuss in the Application WG, as SSO proxy is one of the most efficient tool to allow clients to access services that provides different authentication mechanisms. There are already some activities going on in the framework of EGI or INDIGO EU funded projects. SSO proxies do not affect the configuration of the service and they will benefit of the securityMethod defined in this document. Thanks again Tom.

I think that this is an excellent topic to discuss in the next GWS-WG session for a note.

-- TomMcGlynn - 2016-10-19

Knowledge Discovery in Databases Interest Group ( Kai Polsterer )

Theory Interest Group ( _Carlos Rodrigo )

Standards and Processes Committee ( Françoise Genova)