/[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 3933 - (hide annotations)
Mon Apr 10 09:35:56 2017 UTC (3 years, 5 months ago) by taffoni
File MIME type: application/x-tex
File size: 24441 byte(s)
New Acknowledgements section


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

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