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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 3280 - (show annotations)
Thu Apr 7 15:13:56 2016 UTC (4 years, 4 months ago) by taffoni
File MIME type: application/x-tex
File size: 24015 byte(s)
Conclusions§

1 \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{Brian Majour, Guy Rixon, Andr\`e Schaaff, Giuliano Taffoni}
16
17 \editor{Giuliano Taffoni}
18
19 \previousversion[http://www.ivoa.net/documents/cover/SSOAuthMech-20080124.html]{REC-1.0}
20 \previousversion[http://www.ivoa.net/documents/cover/SSOAuthMech-20070904.html]{PR-20070904}
21 \previousversion[http://www.ivoa.net/documents/cover/SSOAuthMech-20070621.html]{PR-20070621}
22 \previousversion[http://www.ivoa.net/documents/cover/SSOAuthMech-20060519.html]{WD-20060519}
23
24
25 \begin{document}
26 \begin{abstract}
27 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.
28 \end{abstract}
29
30
31 \section*{Acknowledgments}
32
33 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.
34 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).
35
36
37 \section*{Conformance-related definitions}
38 The words ``MUST'', ``SHALL'', ``SHOULD'', ``MAY'', ``RECOMMENDED'', and
39 ``OPTIONAL'' (in upper or lower case) used in this document are to be
40 interpreted as described in IETF standard, \citet{std:RFC2119}.
41
42 The \emph{Virtual Observatory (VO)} is
43 general term for a collection of federated resources that can be used
44 to conduct astronomical research, education, and outreach.
45 The \href{http://www.ivoa.net}{International
46 Virtual Observatory Alliance (IVOA)} is a global
47 collaboration of separately funded projects to develop standards and
48 infrastructure that enable VO applications.
49
50
51 \section{Introduction}
52 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.
53 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.
54
55 \subsection{Role within the VO Architecture}
56
57 \begin{figure}
58 \centering
59
60 % Get the architecture diagram from the TCG chair
61 % http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaTCG
62 % If they give you a PDF, for now dumb it down to a png by
63 % convert -antialias -density 72x72 archdiag.pdf archdiag.png
64 % Oh -- Notes don't need this; you'd have to remove archdiag.png
65 % from FIGURES in the Makefile, too.
66 \includegraphics[width=0.9\textwidth]{SSO_image001.png}
67 \caption{Architecture diagram for this document}
68 \label{fig:archdiag}
69 \end{figure}
70
71 Fig.~\ref{fig:archdiag} shows the role this document plays within the
72 IVOA architecture \citep{note:VOARCH}.
73
74
75 \section{Scope of this standard}
76 \subsection{Requirements}
77 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.
78 The registration of the service interface SHALL contain an XML element
79 of type \xmlel{SecurityMethod} as specified in the XML schema for
80 VOResource \citep{std:VOR}. The value of this element distinguishes the
81 authentication mechanism using the values stated in the sections below.
82 Services registered without the metadata alluded to above need not
83 support any authentication mechanism. If they do require authentication,
84 they MAY use either the IVOA-standard mechanisms or others that are not
85 IVOA standards.
86
87 \subsection{Commentary}
88 The IVOA SSO profile allows the development of a ''realm'' of interoperable services and clients.
89 Service providers opt in to this realm by implementing this current standard and by registering accordingly in the IVOA registry.
90 This allows clients to discover a secured service through the registry and to be able to use it without
91 being customized for the details of the specific service.
92
93 Services within the Virtual Observatory that are not intended to be widely interoperable need not opt in to the SSO realm.
94 In particular, ''private'' services, accessed by web browsers and protected by passwords, are allowed.
95 However, these private services should be reworked to follow the IVOA standard if they are later promoted to a wider audience.
96
97 An example of a registration for a secured interface follows.
98 \begin{lstlisting}[language=XML]
99 <interface xmlns:vs='ivo://www.ivoa.net/xml/VODataService/v1.0'
100 xsi:type='vs:ParamHTTP'>
101 <accessURL>http://some.where/some/thing</accessURL>
102 <securityMethod>ivo://ivoa.net/sso#saml2.0</securityMethod>
103 </interface>
104 \end{lstlisting}
105
106 More than one {\xmlel securityMethod} can be specified:
107 \begin{lstlisting}[language=XML]
108 <interface xmlns:vs='ivo://www.ivoa.net/xml/VODataService/v1.0'
109 xsi:type='vs:ParamHTTP'>
110 <accessURL>http://some.where/some/thing</accessURL>
111 <securityMethod>ivo://ivoa.net/sso#saml2.0</securityMethod>
112 <securityMethod>ivo://ivoa.net/sso#cookie</securityMethod>
113 <securityMethod>ivo://ivoa.net/sso#OpenID</securityMethod>
114 </interface>
115 \end{lstlisting}
116
117 The order of the \xmlel{securityMethod} elements determines the priority of the method to use, in the example above the preferred method to access
118 the service is {\em SAML}, than {\em cookies} and finally if the other are not available OpenID.
119
120 \section{Approved authentication mechanisms}
121
122 The following authentication mechanisms are approved for use in the SSO profile.
123 \begin{itemize}
124 \item No authentication required.
125 \item HTTP Basic Authentication
126 \item Transport Layer Security (TLS) with passwords.
127 \item Transport Layer Security (TLS) with client certificates.
128 \item Cookies
129 \item Open Authentication (OAuth)
130 \item Security Assertion Markup Language (SAML)
131 \item OpenID
132 \end{itemize}
133
134 The mechanism is associated with the interface provided by the service and registered in the IVOA registry.
135
136 \begin{table}[th] \begin{tabular}{p{0.45\textwidth}p{0.64\textwidth}} \sptablerule
137 \textbf{SSO mechanism}&\textbf{\xmlel{<securityMethod>}}\\ \sptablerule
138 No authentication required & none\\
139 HTTP Basic Authentication &
140 \xmlel{https://www.w3.org/Protocols/HTTP/ 1.0/spec.html\#BasicAA}\\
141 TLS with password & \xmlel{ivo://ivoa.net/sso\#tls-with-password} \\
142 TLS with client certificate & \xmlel{ivo://ivoa.net/sso\#tls-with-certificate} \\
143 Cookies & \xmlel{ivo://ivoa.net/sso\#cookie} \\
144 Open Authentication & \xmlel{ivo://ivoa.net/sso\#OAuth} \\
145 SAML & \xmlel{ivo://ivoa.net/sso\#saml2.0} \\
146 OpenID & \xmlel{ivo://ivoa.net/sso\#OpenID} \\
147 \sptablerule
148 \caption{List of approved authentication mechanisms and the corresponding securityMethod}
149 \label{table:SMtable}
150 \end{tabular}
151 \end{table}
152
153 Services that are registered with a IVOA registry as having a {\em WebService} type interface
154 \citep{ivo:resource} SHALL support OAuth, or SHALL support cookies or SHALL support TLS with client
155 certificates or SHALL require no authentication.
156 Interfaces by which a user logs in to the SSO system SHALL support either
157 TLS with client certificates, or TLS with passwords, or SAML or a combination of them
158
159 \section{HTTP Basic Authentication}
160 \subsection{Requirements}
161 Services using HTTP basic authentication SHALL use the authentication mechanism described in the RFC7235 \citep{std:RFC7235}
162 that updates RFC2617 \citep{std:RFC2617}.
163 Interfaces using this mechanism SHALL be be registered with the security method
164
165 \texttt{https://www.w3.org/Protocols/HTTP/1.0/spec.html\#BasicAA}
166
167 \subsection{Commentary}
168 HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge
169 a client request and by a client to provide authentication information.
170 The HTTP authentication framework does not define a single mechanism for maintaining the confidentiality of credentials.
171 HTTP depends on the security properties of the underlying transport- or session-level connection to provide
172 confidential transmission of header fields. Connection secured with TLS are recommended prior to exchanging any credentials.
173
174 \section{Details of TLS}
175 \subsection{Requirements}
176 Services using Transport Layer Security (TLS) SHALL do so according to the TLS v1.2 standard RFC5246 \citep{std:RFC5246}.
177
178 \subsection{Commentary}
179 TLS supersedes the Secure Sockets Layer that is an outdated cryptographic protocol.
180 TLS v1.0 was based on SSL v3.0; the current version of TLS is V1.2 described in by \citet{std:RFC5246}.
181 TLS v1.2 is backwards compatible with TLS v1.0, TLS v1.1 and SSL v3.0.
182 ``TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages;
183 thus, supporting all of them is relatively easy.[...] TLS 1.2 clients that wish to support SSL 2.0 servers MUST
184 send version 2.0 CLIENT-HELLO messages defined in SSL2.'' \citep{std:RFC5246}.
185
186 \section{Details of TLS-with-client-certificate}
187 \subsection{Requirements}
188 Certificates SHALL be transmitted and checked according to the TLS v1.2 standard RFC5246.
189
190 Services implementing TLS MUST support certificate chains including proxy certificates according to RFC6818 \citep{std:RFC6818}.
191
192 Interfaces using this mechanism SHALL be be registered with the security method
193
194 \texttt{ivo://ivoa.net/sso\#tls-with-certificate}.
195
196 \subsection{Commentary}
197 When Mutual Certificate Authentication is configured for REST services, both, the client and the service perform
198 identity verification or authentication through X.509 certificates.
199
200 The client authenticates the service during the initial SSL handshake, when the server sends the client a certificate to authenticate itself.
201
202 \section{Details of TLS-with-password}
203 \subsection{Requirements}
204 The user-name and password SHALL be passed in the message protected by the TLS mechanism,
205 not as part of the mechanism itself. The ``HTTP basic authentication'' should be used with particular attention.
206
207 Interfaces using this mechanism SHALL be be registered with the security method
208
209 \texttt{ivo://ivoa.net/sso\#tls-with-password}.
210
211 \subsection{Commentary}
212 ``HTTP basic authentication'' passes the user-name and password in the HTTP headers,
213 assuming that the credentials are not a natural part of the message body.
214 This standard applies the TLS-with-Password mechanism only to the special case of logging in to the SSO realm.
215 Hence, the user name and password are logically part of the message body, not the message header.
216
217 \section{The use of Cookies}
218 \subsection{Requirements}
219 Cookie-Based Authentication uses server side cookies to authenticate the user on every request.
220 The way to manage cookies for authentication is described in RFC6265 \citep{std:RFC6265}.
221
222 Interfaces using this mechanism SHALL be be registered with the security method
223
224 \texttt{ivo://ivoa.net/sso\#cookie}.
225
226
227 \subsection{Commentary}
228 RESTful web services should use session-based authentication, either by establishing a session token via a POST or
229 by using an API key as a POST body argument or as a cookie.
230 User names, passwords, session tokens, and API keys should not appear in the URL,
231 as this can be captured in web server logs, which makes them intrinsically valuable.
232 \begin{figure}
233 \centering
234 \includegraphics[width=0.9\textwidth]{SSO_image002.png}
235 \caption{Simplified picture of SAML 2.0 authentication.}
236 \label{fig:saml}
237 \end{figure}
238
239 \section{Details on SAML authentication}
240 \subsection{Requirements}
241 Services using SAML authentication mechanisms SHALL do so according to the
242 saml-core-2.0-os OASIS standard \citep{std:SAML}.
243 SAML includes protocols and protocol bindings and security \citep{std:SAMLB}.
244
245 Interfaces using this mechanism SHALL be be registered with the security method
246
247 \texttt{ivo://ivoa.net/sso\#saml2.0}.
248
249
250 \subsection{Commentary}
251 SAML presumes two primary roles in any transaction: the organisation where the identity is established,
252 known as the Identity Provider (``IdP''), or Asserting Party (``AP'');
253 and the organisation which (for this transaction) wants to use this identity, known as the Service Provider (``SP''),
254 or Relying Party (``RP'').
255
256 A user attempts to access an application with the Service Provider.
257 The SP needs to establish the identity of this user, and so sends an authentication request to the Identity Provider.
258
259 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.
260 Now the SP knows who the user is, and can process that user accordingly (see Fig.~\ref{fig:saml}).
261 \begin{figure}
262 \centering
263 \includegraphics[width=0.9\textwidth]{SSO_image003.png}
264 \caption{Simplified picture of OAuth 2.0 authentication.}
265 \label{fig:oauth}
266 \end{figure}
267
268 SAML2.0 protocol allows also to implement authentication service discovery mechanisms. SAML2.0 defines a browser-based protocol
269 by which a centralized discovery service can provide a requesting service provider with the unique identifier of an
270 identity provider that can authenticate a principal. In this way
271
272
273 \section{Details on OAuth}
274 \subsection{Requirements}
275 Services using OAuth authentication mechanisms SHALL do so according to the RFC6749 \citep{std:RFC6742}.
276
277 Interfaces using this mechanism SHALL be be registered with the security method
278
279 \texttt{ivo://ivoa.net/sso\#OAuth}.
280
281
282 \subsection{Commentary}
283 Open Authentication 2.0 (also in conjunction with OpenID Connect) is actually the adopted standard
284 to handle identity in the framework of RESTful web services.
285 OAuth is used when an application is making a request on behalf of a user.
286
287 OAuth introduces the notion of an `authorization token', a `refresh token' and Authorization Service (AS).
288 The `authorization' token states that the client application has the right to access services on the server (see Fig.~\ref{fig:oauth}).
289 However, it does not supersede any access control decisions that the server-side application might make.
290
291 OAuth is related to delegate credential from an application to another.
292
293 \section{Details on OpenID}
294 \subsection{Requirements}
295 Services using OpenID authentication mechanisms SHALL do so according to the OpenID Foundation standards \citep{std:openid}
296
297 Interfaces using this mechanism SHALL be be registered with the security method
298
299 \texttt{ivo://ivoa.net/sso\#OpenID}.
300
301
302 \subsection{Commentary}
303 OpenID is an open and decentralized authentication and identity system. OpenID relying parties do not manage end user credentials
304 such as passwords or any other sensitive information which makes authentication and identity management much simpler and secure.
305 In a RESTful environment OpenID Connect \citep{std:openidconnect} is commonly adopted as authentication solution. ``OpenID Connect is a simple identity
306 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
307 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}.
308
309 \section{Conclusions}
310 This document presents a list of existing security standards, to implement when developing a service that requires authentication mechanism. The list includes the most frequently used standards at the time this document has been produced.
311
312 In this document we are presenting two types of SSO protocols: "local" and "federated".
313 Local SSO provides solutions for keeping a repository of usernames and passwords
314 that could be used transparently across several internal applications but it is local to one domain/service.
315
316 Federated identity means linking and using the electronic identities a user has across several identity management systems.
317 In simpler terms, a service does not necessarily need to obtain and store users? credentials in order to authenticate them. Instead, the service (or we application) can use an identity management system that is already storing a user?s electronic identity
318 to authenticate the user?given, of course, that the application trusts that identity management system.
319 Federated identities are convenient for users, since they don?t have to keep a set of usernames and passwords for every single application that they use and for service providers that do not need to store and manage credential.
320
321 Local SSO is managed by the following protocols: HTTP Basic Authentication, Transport Layer Security (TLS) with passwords, and cookies
322 OAuth, SAML, OpenID and Transport Layer Security (TLS) with client certificates (thanks to the CA trust) are protocol that
323 allow to implement federated SSO.
324
325 The choice the authentication method to use is related to the project/service requirements, we suggest at least to implement
326 a local authentication based on Transport Layer Security (TLS) with passwords, that allow a reasonable security
327 framework for exchanging authentication tokens.
328
329 More complex projects/sevices that needs to offer resources to a large distributed communities should prefer federated identities.
330 For example SAML2.0 is the protocol used to build the EduGain World wide identity federation for education and research.
331
332
333
334 \appendix
335 \section{VOResource SecurityMethod}
336 This Appendix presents an extract of the VOResource Description XML schema.
337 Here we present the part of the schema regarding the \xmlel{SecurityMethod} element
338 to facilitate the reader identify the relevant schema sections in the VOResource Description.
339
340
341 \begin{lstlisting}[language=xml,basicstyle=\footnotesize]
342 <xs:schema xmlns="http://www.w3.org/2001/XMLSchema"
343 xmlns:xs="http://www.w3.org/2001/XMLSchema"
344 xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
345 xmlns:vm="http://www.ivoa.net/xml/VOMetadata/v0.1"
346 targetNamespace="http://www.ivoa.net/xml/VOResource/v1.0"
347 elementFormDefault="unqualified" attributeFormDefault="unqualified" version="1.02">
348 <xs:annotation>...</xs:annotation>
349 <xs:simpleType name="UTCTimestamp">...</xs:simpleType>
350 <xs:simpleType name="UTCDateTime">...</xs:simpleType>
351 <xs:complexType name="Resource">...</xs:complexType>
352 <xs:simpleType name="ValidationLevel">...</xs:simpleType>
353 <xs:complexType name="Validation">...</xs:complexType>
354 <xs:simpleType name="AuthorityID">...</xs:simpleType>
355 <xs:simpleType name="ResourceKey">...</xs:simpleType>
356 <xs:simpleType name="IdentifierURI">...</xs:simpleType>
357 <xs:simpleType name="ShortName">...</xs:simpleType>
358 <xs:complexType name="Curation">...</xs:complexType>
359 <xs:complexType name="ResourceName">...</xs:complexType>
360 <xs:complexType name="Contact">...</xs:complexType>
361 <xs:complexType name="Creator">...</xs:complexType>
362 <xs:complexType name="Date">...</xs:complexType>
363 <xs:complexType name="Content">...</xs:complexType>
364 <xs:complexType name="Source">...</xs:complexType>
365 <xs:simpleType name="Type">...</xs:simpleType>
366 <xs:simpleType name="ContentLevel">...</xs:simpleType>
367 <xs:complexType name="Relationship">...</xs:complexType>
368 <xs:complexType name="Organisation">...</xs:complexType>
369 <xs:complexType name="Service">...</xs:complexType>
370 <xs:simpleType name="Rights">...</xs:simpleType>
371 <xs:complexType name="Capability">...</xs:complexType>
372 <xs:complexType name="Interface" abstract="true">
373 <xs:annotation>...</xs:annotation>
374 <xs:sequence>
375 <xs:element name="accessURL" type="vr:AccessURL"
376 minOccurs="1" maxOccurs="unbounded">...</xs:element>
377 <xs:element name="securityMethod" type="vr:SecurityMethod"
378 minOccurs="0" maxOccurs="unbounded">
379 <xs:annotation>
380 <xs:documentation> the mechanism the client must employ to
381 gain secure access to the service.
382 </xs:documentation>
383 <xs:documentation> when more than one method is listed, each one
384 must be employed to gain access.
385 </xs:documentation>
386 </xs:annotation>
387 </xs:element>
388 </xs:sequence>
389 <xs:attribute name="version" type="xs:string" default="1.0">...</xs:attribute>
390 <xs:attribute name="role" type="xs:NMTOKEN">...</xs:attribute>
391 </xs:complexType>
392 <xs:complexType name="AccessURL">...</xs:complexType>
393 <xs:complexType name="SecurityMethod">
394 <xs:annotation>
395 <xs:documentation>a description of a security mechanism.</xs:documentation>
396 <xs:documentation> this type only allows one to refer to the mechanism via a URI.
397 Derived types would allow for more metadata.
398 </xs:documentation>
399 </xs:annotation>
400 <xs:sequence/>
401 <xs:attribute name="standardID" type="xs:anyURI">
402 <xs:annotation>
403 <xs:documentation> A URI identifier for a standard security mechanism. </xs:documentation>
404 <xs:documentation>
405 This provides a unique way to refer to a security specification standard.
406 The use of an IVOA identifier here implies that a VOResource
407 description of the standard is registered and accessible.
408 </xs:documentation>
409 </xs:annotation>
410 </xs:attribute>
411 </xs:complexType>
412 <xs:complexType name="WebBrowser">...</xs:complexType>
413 <xs:complexType name="WebService">...</xs:complexType>
414 </xs:schema>
415 \end{lstlisting}
416
417
418 \section{Changes from Previous Versions}
419
420
421 \subsection {Changes from v. 1.01}
422 \begin{itemize}
423 \item We remove all the references to SOAP as deprecated from IVOA
424 \item We add new security methods ad relative discussion sessions: OpenID, SAML, Cookies, HTTP basic authentication
425 \end{itemize}
426
427
428 \bibliography{ivoatex/ivoabib,SSOAuthMech}
429
430
431 \end{document}

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