/[volute]/trunk/projects/grid/sso/doc/SSOAuthMech.tex
ViewVC logotype

Annotation of /trunk/projects/grid/sso/doc/SSOAuthMech.tex

Parent Directory Parent Directory | Revision Log Revision Log


Revision 3172 - (hide annotations)
Fri Dec 4 11:08:17 2015 UTC (4 years, 9 months ago) by taffoni
File MIME type: application/x-tex
File size: 20611 byte(s)
SSO specification document

1 taffoni 3172 \documentclass[11pt,a4paper]{ivoa}
2     \input tthdefs
3    
4     \usepackage{listings}
5     %\lstloadlanguages{sh,make,xml,[latex]tex}
6     \lstset{flexiblecolumns=true,numberstyle=\small,showstringspaces=False,
7     identifierstyle=\texttt,defaultdialect=[latex]tex,language=tex}
8    
9    
10     \title{IVOA Single-Sign-On Profile: Authentication Mechanisms}
11    
12     \ivoagroup{http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices}
13    
14     %\author[????URL????]{http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices}
15     \author{Grid and Web Services Working Group}
16    
17     \editor{Guy Rixon, Andre\'e Schaaff, Giuliano Taffoni
18     }
19    
20     \previousversion[http://www.ivoa.net/documents/cover/SSOAuthMech-20080124.html]{http://www.ivoa.net/documents/cover/SSOAuthMech-20080124.html
21     http://www.ivoa.net/documents/cover/SSOAuthMech-20070904.html
22     http://www.ivoa.net/documents/cover/SSOAuthMech-20070621.html
23     http://www.ivoa.net/documents/cover/SSOAuthMech-20060519.html
24     }
25     %\previousversion{This is the first public release}
26    
27    
28     \begin{document}
29     \begin{abstract}
30     Approved client-server authentication mechanisms are described for the IVOA single-sign-on profile: No Authentication; HTTP Basic Authentication; TLS with passwords; TLS with client certificates; Cookies; Open Authentication; Security Assertion Markup Language; OpenID. Normative rules are given for the implementation of these mechanisms, mainly by reference to pre-existing standards. The Authorization mechanisms are out of the scope of this document.
31     \end{abstract}
32    
33    
34     \section*{Acknowledgments}
35    
36     This document derives from discussions among the Grid and Web Services working-group of IVOA. It is particularly informed by prototypes built by Matthew Graham (Caltech/US-NVO), Paul Harrison (ESO/EuroVO), David Morris (Cambridge/AstroGrid) and Raymond Plante (NCSA/US-NVO). The prior art for the use of proxy certificates comes from the Globus Alliance.
37     This document has been developed with support from the National Science Foundation's Information Technology Research Program under Cooperative Agreement AST0122449 with The Johns Hopkins University, from the UK Particle Physics and Astronomy Research Council (PPARC) and from the Europena Commission's Sixth Framework Program via the Optical Infrared Coordination Network (OPTICON).
38    
39    
40     \section*{Conformance-related definitions}
41     The words ``MUST'', ``SHALL'', ``SHOULD'', ``MAY'', ``RECOMMENDED'', and
42     ``OPTIONAL'' (in upper or lower case) used in this document are to be
43     interpreted as described in IETF standard, \citet{std:RFC2119}.
44    
45     The \emph{Virtual Observatory (VO)} is
46     general term for a collection of federated resources that can be used
47     to conduct astronomical research, education, and outreach.
48     The \href{http://www.ivoa.net}{International
49     Virtual Observatory Alliance (IVOA)} is a global
50     collaboration of separately funded projects to develop standards and
51     infrastructure that enable VO applications.
52    
53    
54     \section{Introduction}
55     IVOA's single-sign-on architecture is a system in which users assign cryptographic credentials to user agents so that the agents may act with the user?s identity and access rights. This standard describes how agents use those credentials to authenticate the user's identity in requests to services. This standard describes also the authentication mechanism of an application or a service making a call (on behalf of someone or something else) to an API or to another service
56     This document is essentially a {\em profile} against existing security standards; that is, it describes how an existing standard should be applied in an IVOA application to support single sign-on capabilities in the IVOA. In the following sections, we make specific references to details spelled out in these standards. For the purposes of validating against this standard, those referenced documents should be consulted for a full explanation of those details. Unfortunately, a reader that is unfamiliar with these external standards might find this specification confusing. To alleviate this problem, each major section is concluded by a Commentary subsection that provides some explanations of the detailed terms and concepts being referred to. The Commentary subsection may also provide recommended scenarios for how this specification might actually be realised. Note that the statements in the Commentary subsections are non-normative and should not be considered part of precise specification; nevertheless, they are indicative of the intended spirit of this document.
57    
58     \subsection{Role within the VO Architecture}
59    
60     \begin{figure}
61     \centering
62    
63     % Get the architecture diagram from the TCG chair
64     % http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaTCG
65     % If they give you a PDF, for now dumb it down to a png by
66     % convert -antialias -density 72x72 archdiag.pdf archdiag.png
67     % Oh -- Notes don't need this; you'd have to remove archdiag.png
68     % from FIGURES in the Makefile, too.
69     \includegraphics[width=0.9\textwidth]{SSO_image001.png}
70     \caption{Architecture diagram for this document}
71     \label{fig:archdiag}
72     \end{figure}
73    
74     Fig.~\ref{fig:archdiag} shows the role this document plays within the
75     IVOA architecture \citep{note:VOARCH}.
76    
77    
78     \section{Scope of this standard}
79     \subsection{Requirements}
80     When a service is registered in an IVOA registry, that services resource document may include metadata expressing conformance to one or more of the authentication mechanisms approved in the IVOA SSO profile. Such a service must implement those mechanisms as described in this document, and clients of the service must participate in the mechanism when calling the service. Is a service does not provide any SSO specification it is assumed that no authentication is required.
81     The registration of the service interface shall contain an XML element of type {\xmlel SecurityMethod} as specified in the XML schema for VOResource [VOResource]. The value of this element distinguished the authentication mechanism using the values stated in the sections below.
82     Services registered without the metadata alluded to above need not support any authentication mechanism. If they do require authentication, they may use either the IVOA-standard mechanisms or others that are not IVOA standards.
83    
84     \subsection{Commentary}
85     The IVOA SSO profile allows the development of a ''realm'' of interoperable services and clients.
86     Service providers opt in to this realm by implementing this current standard and by registering accordingly in the IVOA registry.
87     This allows clients to discover a secured service through the registry and to be able to use it without
88     being customized for the details of the specific service.
89    
90     Parts of the IVOA that are not intended to be widely interoperable need not opt in to the SSO realm.
91     In particular, ''private'' services, accessed by web browsers and protected by passwords, are allowed.
92     However, these private services should be reworked to follow the IVOA standard if they are later promoted to a wider audience.
93    
94     An example of a registration for a secured interface follows.
95     \begin{lstlisting}[language=XML]
96     <interface xmlns:vs:=''ivo://www.ivoa.net/xml/VODataService/v1.0''
97     xsi:type=''vs:ParamHTTP''>
98     <accessURL>http://some.where/some/thing</accessURL>
99     <securityMethod>ivo://ivoa.net/sso#saml2.0</securityMethod>
100     </interface>
101     \end{lstlisting}
102    
103     More than one {\xmlel securityMethod} can be specified:
104     \begin{lstlisting}[language=XML]
105     <interface xmlns:vs:=''ivo://www.ivoa.net/xml/VODataService/v1.0''
106     xsi:type=''vs:ParamHTTP''>
107     <accessURL>http://some.where/some/thing</accessURL>
108     <securityMethod>ivo://ivoa.net/sso#saml2.0</securityMethod>
109     <securityMethod>ivo://ivoa.net/sso#cookie</securityMethod>
110     <securityMethod>ivo://ivoa.net/sso#OpenID</securityMethod>
111     </interface>
112     \end{lstlisting}
113    
114     The order identify the priority of the method to use, in the example above the preferred method to access
115     the service is {\em SAML}, than {cookies} and finally if the other are not available OpenID.
116    
117     \section{Approved authentication mechanisms}
118     \subsection{Requirements}
119     The following authentication mechanisms are approved for use in the SSO profile.
120     \begin{itemize}
121     \item No authentication required.
122     \item HTTP Basic Authentication
123     \item Transport Layer Security (TLS) with passwords.
124     \item Transport Layer Security (TLS) with client certificates.
125     \item Cookies
126     \item Open Authentication (OAuth)
127     \item Security Assertion Markup Language (SAML)
128     \item OpenID
129     \end{itemize}
130    
131     The mechanism is associated with the interface provided by the service and registered in the IVOA registry.
132    
133     \begin{table}[thm] \begin{tabular}{p{0.45\textwidth}p{0.64\textwidth}} \sptablerule
134     \textbf{SSO mechanism}&\textbf{\xmlel{<securityMethod>}}\\ \sptablerule
135     No authentication required & none\\
136     HTTP Basic Authentication &
137     \xmlel{http//www.w3.org/Protocols/HTTP/ 1.0/spec/html\#BasicAA}\\
138     TLS with password & \xmlel{ivo://ivoa.net/sso\#tls-with-password} \\
139     TLS with client certificate & \xmlel{ivo://ivoa.net/sso\#tls-with-certificate} \\
140     Cookies & \xmlel{ivo://ivoa.net/sso\#cookie} \\
141     Open Authentication & \xmlel{ivo://ivoa.net/sso\#OAuth} \\
142     SAML & \xmlel{ivo://ivoa.net/sso\#saml2.0} \\
143     OpenID & \xmlel{ivo://ivoa.net/sso\#OpenID} \\
144     \sptablerule
145     \caption{List of approved authentication mechanisms and the corresponding securityMethod}
146     \label{table:SMtable}
147     \end{tabular}
148     \end{table}
149    
150     Services that are registered with a IVOA registry as having a {em WebService} type interface
151     \citep{ivo:resource} shall support OAuth, or shall support cookies or shall support TLS with client
152     certificates or shall require no authentication.
153     Interfaces by which a user logs in to the SSO system shall support either
154     TLS with client certificates, or TLS with passwords, or SAML or a combination of the them
155    
156     \section{HTTP Basic Authentication}
157     \subsection{Requirements}
158     Services using HTTP basic authentication shall use the authentication mechanism described in the RFC7235 \citep{std:RFC7235}
159     that updates RFC2617 \citep{std:RFC2617}.
160     Interfaces using this mechanism shall be be registered with the security method
161    
162     \texttt{http://www.w3.org/Protocols/HTTP/1.0/spec/html\#BasicAA}
163    
164     \subsection{Commentary}
165     HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge
166     a client request and by a client to provide authentication information.
167     The HTTP authentication framework does not define a single mechanism for maintaining the confidentiality of credentials.
168     HTTP depends on the security properties of the underlying transport- or session-level connection to provide
169     confidential transmission of header fields. Connection secured with TLS are recommended prior to exchanging any credentials.
170    
171     \section{Details of TLS}
172     \subsection{Requirements}
173     Services using Transport Layer Security (TLS) shall do so according to the TLS v1.2 standard RFC5246 \citep{std:RFC5246}.
174    
175     \subsection{Commentary}
176     TLS supersedes the Secure Sockets Layer that is an outdated cryptographic protocol.
177     TLS v1.0 was based on SSL v3.0; the actual version of TLS is V1.2 described in by \citet{std:RFC5246}.
178     TLS v1.2 is back-compatible with TLS v1.0, TLS v1.1 and SSL v3.0.
179     ``TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages;
180     thus, supporting all of them is relatively easy.[...] TLS 1.2 clients that wish to support SSL 2.0 servers MUST
181     send version 2.0 CLIENT-HELLO messages defined in [SSL2].'' \citep{std:RFC5246}.
182    
183     \section{Details of TLS-with-client-certificate}
184     \subsection{Requirements}
185     Certificates shall be transmitted and checked according to the TLS v1.2 standard [RFC5246].
186    
187     Services implementing TLS must support certificate chains including proxy certificates according to RFC6818 \citep{std:RFC6818}.
188    
189     Interfaces using this mechanism shall be be registered with the security method \texttt{ivo://ivoa.net/sso\#tls-with-client-certificate}.
190    
191     \subsection{Commentary}
192     When Mutual Certificate Authentication is configured for REST services, both, the client and the service perform
193     identity verification or authentication through X.509 certificates.
194    
195     The client authenticates the service during the initial SSL handshake, when the server sends the client a certificate to authenticate itself.
196    
197     \section{Details of TLS-with-password}
198     \subsection{Requirements}
199     The user-name and password shall be passed in the message protected by the TLS mechanism,
200     not as part of the mechanism itself. The ``HTTP basic authentication'' should be used with particular attention.
201    
202     Interfaces using this mechanism shall be be registered with the security method \texttt{ivo://ivoa.net/sso\#tls-with-password}.
203    
204     \subsection{Commentary}
205     ``HTTP basic authentication'' passes the user-name and password in the HTTP headers,
206     assuming that the credentials are not a natural part of the message body.
207     This standard applies the TLS-with-Password mechanism only to the special case of logging in to the SSO realm.
208     Hence, the user name and password are logically part of the message body, not the message header.
209    
210     \section{The use of Cookies}
211     \subsection{Requirements}
212     Cookie-Based Authentication uses server side cookies to authenticate the user on every request.
213     The way to manage cookies for authentication is described in RFC6265 \citep{std:RFC6265}.
214    
215     \subsection{Commentary}
216     RESTful web services should use session-based authentication, either by establishing a session token via a POST or
217     by using an API key as a POST body argument or as a cookie.
218     User names, passwords, session tokens, and API keys should not appear in the URL,
219     as this can be captured in web server logs, which makes them intrinsically valuable.
220     \begin{figure}
221     \centering
222     \includegraphics[width=0.9\textwidth]{SSO_image002.png}
223     \caption{Simplified picture of SAML 2.0 authentication.}
224     \label{fig:saml}
225     \end{figure}
226    
227     \section{Details on SAML authentication}
228     \subsection{Requirements}
229     Services using SAML authentication mechanisms shall shall do so according to the
230     saml-core-2.0-os OASIS standard \citep{std:SAML}.
231     SAML includes protocols and protocol bindings and security \citep{std:SAMLB}.
232    
233     \subsection{Commentary}
234     SAML presumes two primary roles in any transaction: the organisation where the identity is established,
235     known as the Identity Provider (``IdP''), or Asserting Party (``AP'');
236     and the organisation which (for this transaction) wants to use this identity, known as the Service Provider (``SP''),
237     or Relying Party (``RP'').
238    
239     A user attempts to access an application with the Service Provider.
240     The SP needs to establish the identity of this user, and so sends an authentication request to the Identity Provider.
241    
242     The user authenticate with the IDP (IDP is taking care of the authentication mechanisms and protocols e.g. Kerberos, ldap etc.) so the IdP can send back an `Assertion' to the SP.
243     Now the SP knows who the user is, and can process that user accordingly (see Fig.~\ref{fig:saml}).
244     \begin{figure}
245     \centering
246     \includegraphics[width=0.9\textwidth]{SSO_image003.png}
247     \caption{Simplified picture of OAuth 2.0 authentication.}
248     \label{fig:oauth}
249     \end{figure}
250    
251    
252    
253     SAML2.0 allow also to service discovery mechanisms
254    
255     \section{Details on OAuth}
256     \subsection{Requirements}
257     Services using OAuth authentication mechanisms shall do so according to the RFC6749 \citep{std:RFC6742}.
258    
259     \subsection{Commentary}
260     Open Authentication 2.0 (also in conjunction with OpenID Connect) is actually the adopted standard
261     to handle identity in the framework of RESTful web services.
262     OAuth is used when an application is making a request on behalf of a user.
263    
264     OAuth introduces the notion of an `authorization token', a `refresh token' and Authorization Service (AS).
265     The `authorization' token states that the client application has the right to access services on the server (see Fig.~\ref{fig:oauth}).
266     However, it does not supersede any access control decisions that the server-side application might make.
267    
268     OAuth is related to delegate credential from an application to another.
269    
270     \section{Details on OpenID}
271     \subsection{Requirements}
272     Services using OpenID authentication mechanisms shall do so according to the OpenID Foundation standards \citep{std:openid}
273    
274     \subsection{Commentary}
275     OpenID is an open and decentralized authentication and identity system. OpenID relying parties do not manage end user credentials
276     such as passwords or any other sensitive information which makes authentication and identity management much simpler and secure.
277     In a RESTful environment OpenID Connect \citep{std:openidconnect} is commonly adopted as authentication solution. ``OpenID Connect is a simple identity
278     layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication
279     performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner.'' \citep{std:openid}.
280    
281     \appendix
282     \section{VOResource SecurityMethod extract}
283    
284     \begin{lstlisting}[language=XSLT]
285     <xs:schema xmlns="http://www.w3.org/2001/XMLSchema"
286     xmlns:xs="http://www.w3.org/2001/XMLSchema"
287     xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
288     xmlns:vm="http://www.ivoa.net/xml/VOMetadata/v0.1"
289     targetNamespace="http://www.ivoa.net/xml/VOResource/v1.0"
290     elementFormDefault="unqualified" attributeFormDefault="unqualified" version="1.02">
291     <xs:annotation>...</xs:annotation>
292     <xs:simpleType name="UTCTimestamp">...</xs:simpleType>
293     <xs:simpleType name="UTCDateTime">...</xs:simpleType>
294     <xs:complexType name="Resource">...</xs:complexType>
295     <xs:simpleType name="ValidationLevel">...</xs:simpleType>
296     <xs:complexType name="Validation">...</xs:complexType>
297     <xs:simpleType name="AuthorityID">...</xs:simpleType>
298     <xs:simpleType name="ResourceKey">...</xs:simpleType>
299     <xs:simpleType name="IdentifierURI">...</xs:simpleType>
300     <xs:simpleType name="ShortName">...</xs:simpleType>
301     <xs:complexType name="Curation">...</xs:complexType>
302     <xs:complexType name="ResourceName">...</xs:complexType>
303     <xs:complexType name="Contact">...</xs:complexType>
304     <xs:complexType name="Creator">...</xs:complexType>
305     <xs:complexType name="Date">...</xs:complexType>
306     <xs:complexType name="Content">...</xs:complexType>
307     <xs:complexType name="Source">...</xs:complexType>
308     <xs:simpleType name="Type">...</xs:simpleType>
309     <xs:simpleType name="ContentLevel">...</xs:simpleType>
310     <xs:complexType name="Relationship">...</xs:complexType>
311     <xs:complexType name="Organisation">...</xs:complexType>
312     <xs:complexType name="Service">...</xs:complexType>
313     <xs:simpleType name="Rights">...</xs:simpleType>
314     <xs:complexType name="Capability">...</xs:complexType>
315     <xs:complexType name="Interface" abstract="true">
316     <xs:annotation>...</xs:annotation>
317     <xs:sequence>
318     <xs:element name="accessURL" type="vr:AccessURL"
319     minOccurs="1" maxOccurs="unbounded">...</xs:element>
320     <xs:element name="securityMethod" type="vr:SecurityMethod"
321     minOccurs="0" maxOccurs="unbounded">
322     <xs:annotation>
323     <xs:documentation>
324     the mechanism the client must employ to gain secure access to the service.
325     </xs:documentation>
326     <xs:documentation>
327     when more than one method is listed, each one must be employed to gain access.
328     </xs:documentation>
329     </xs:annotation>
330     </xs:element>
331     </xs:sequence>
332     <xs:attribute name="version" type="xs:string" default="1.0">...</xs:attribute>
333     <xs:attribute name="role" type="xs:NMTOKEN">...</xs:attribute>
334     </xs:complexType>
335     <xs:complexType name="AccessURL">...</xs:complexType>
336     <xs:complexType name="SecurityMethod">
337     <xs:annotation>
338     <xs:documentation>a description of a security mechanism.</xs:documentation>
339     <xs:documentation>
340     this type only allows one to refer to the mechanism via a URI.
341     Derived types would allow for more metadata.
342     </xs:documentation>
343     </xs:annotation>
344     <xs:sequence/>
345     <xs:attribute name="standardID" type="xs:anyURI">
346     <xs:annotation>
347     <xs:documentation>
348     A URI identifier for a standard security mechanism.
349     </xs:documentation>
350     <xs:documentation>
351     This provides a unique way to refer to a security specification standard.
352     The use of an IVOA identifier here implies that a VOResource
353     description of the standard is registered and accessible.
354     </xs:documentation>
355     </xs:annotation>
356     </xs:attribute>
357     </xs:complexType>
358     <xs:complexType name="WebBrowser">...</xs:complexType>
359     <xs:complexType name="WebService">...</xs:complexType>
360     </xs:schema>
361     \end{lstlisting}
362    
363    
364     \section{Changes from Previous Versions}
365    
366    
367     \subsection {Changes from v. 1.01}
368     \begin{itemize}
369     \item We remove all the references to SOAP as deprecated from IVOA
370     \item We add new security methods ad relative discussion sessions: OpenID, SAML, Cookies, HTTP basic authentication
371     \end{itemize}
372    
373    
374     \bibliography{ivoatex/ivoabib,SSOAuthMech}
375    
376    
377     \end{document}

msdemlei@ari.uni-heidelberg.de
ViewVC Help
Powered by ViewVC 1.1.26