第1页 / 共43页
第2页 / 共43页
第3页 / 共43页
第4页 / 共43页
第5页 / 共43页
第6页 / 共43页
第7页 / 共43页
第8页 / 共43页
saml-metadata-2.0-os.pdf
无标题
Metadata for the OASIS Security
Assertion Markup Language (SAML)
V2.0
OASIS Standard, 15 March 2005
Document identifier:
saml-metadata-2.0-os
Location:
http://docs.oasis-open.org/security/saml/v2.0/
Editors:
Scott Cantor, Internet2
Jahan Moreh, Sigaba
Rob Philpott, RSA Security
Eve Maler, Sun Microsystems
SAML V2.0 Contributors:
Conor P. Cahill, AOL
John Hughes, Atos Origin
Hal Lockhart, BEA Systems
Michael Beach, Boeing
Rebekah Metz, Booz Allen Hamilton
Rick Randall, Booz Allen Hamilton
Thomas Wisniewski, Entrust
Irving Reid, Hewlett-Packard
Paula Austel, IBM
Maryann Hondo, IBM
Michael McIntosh, IBM
Tony Nadalin, IBM
Nick Ragouzis, Individual
Scott Cantor, Internet2
RL 'Bob' Morgan, Internet2
Peter C Davis, Neustar
Jeff Hodges, Neustar
Frederick Hirsch, Nokia
John Kemp, Nokia
Paul Madsen, NTT
Steve Anderson, OpenNetwork
Prateek Mishra, Principal Identity
John Linn, RSA Security
Rob Philpott, RSA Security
Jahan Moreh, Sigaba
Anne Anderson, Sun Microsystems
Eve Maler, Sun Microsystems
Ron Monzillo, Sun Microsystems
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
saml-metadata-2.0-os
Copyright © OASIS Open 2005 All Rights Reserved.
15 March 2005
Page 1 of 43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Greg Whitehead, Trustgenix
Abstract:
SAML profiles require agreements between system entities regarding identifiers, binding support
and endpoints, certificates and keys, and so forth. A metadata specification is useful for
describing this information in a standardized way. This document defines an extensible metadata
format for SAML system entities, organized by roles that reflect SAML profiles. Such roles include
that of Identity Provider, Service Provider, Affiliation, Attribute Authority, Attribute Consumer, and
Policy Decision Point.
Status:
This is an OASIS Standard document produced by the Security Services Technical Committee. It
was approved by the OASIS membership on 1 March 2005.
Committee members should submit comments and potential errata to the security-
services@lists.oasis-open.org list. Others should submit them by filling out the web form located
at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=security. The
committee will publish on its web page (http://www.oasis-open.org/committees/security) a catalog
of any changes made to this document.
For information on whether any patents have been disclosed that may be essential to
implementing this specification, and any offers of patent licensing terms, please refer to the
Intellectual Property Rights web page for the Security Services TC (http://www.oasis-
open.org/committees/security/ipr.php).
saml-metadata-2.0-os
Copyright © OASIS Open 2005 All Rights Reserved.
15 March 2005
Page 2 of 43
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
Table of Contents
1 Introduction..................................................................................................................................................5
1.1 Notation................................................................................................................................................5
2 Metadata for SAML V2.0.............................................................................................................................6
2.1 Namespaces .......................................................................................................................................6
2.2 Common Types....................................................................................................................................7
2.2.1 Simple Type entityIDType.............................................................................................................7
2.2.2 Complex Type EndpointType.......................................................................................................7
2.2.3 Complex Type IndexedEndpointType..........................................................................................8
2.2.4 Complex Type localizedNameType..............................................................................................8
2.2.5 Complex Type localizedURIType.................................................................................................9
2.3 Root Elements......................................................................................................................................9
2.3.1 Element .......................................................................................................9
2.3.2 Element ........................................................................................................10
2.3.2.1 Element ......................................................................................................12
2.3.2.2 Element ..................................................................................................12
2.3.2.3 Element ..............................................................................14
2.4 Role Descriptor Elements..................................................................................................................14
2.4.1 Element .........................................................................................................14
2.4.1.1 Element ...................................................................................................15
2.4.2 Complex Type SSODescriptorType...........................................................................................16
2.4.3 Element ...................................................................................................17
2.4.4 Element ....................................................................................................18
2.4.4.1 Element ..............................................................................19
2.4.4.2 Element ...........................................................................................19
2.4.5 Element .........................................................................................20
2.4.6 Element .........................................................................................................20
2.4.7 Element .....................................................................................21
2.5 Element ..........................................................................................................22
2.6 Examples...........................................................................................................................................23
3 Signature Processing................................................................................................................................27
3.1 XML Signature Profile........................................................................................................................27
3.1.1 Signing Formats and Algorithms................................................................................................27
3.1.2 References.................................................................................................................................27
3.1.3 Canonicalization Method............................................................................................................27
3.1.4 Transforms.................................................................................................................................28
3.1.5 KeyInfo........................................................................................................................................28
4 Metadata Publication and Resolution........................................................................................................29
4.1 Publication and Resolution via Well-Known Location........................................................................29
4.1.1 Publication..................................................................................................................................29
4.1.2 Resolution...................................................................................................................................29
4.2 Publishing and Resolution via DNS...................................................................................................29
4.2.1 Publication..................................................................................................................................30
4.2.1.1 First Well Known Rule.........................................................................................................30
4.2.1.2 The Order Field...................................................................................................................30
4.2.1.3 The Preference Field...........................................................................................................30
4.2.1.4 The Flag Field.....................................................................................................................31
4.2.1.5 The Service Field................................................................................................................31
saml-metadata-2.0-os
Copyright © OASIS Open 2005 All Rights Reserved.
15 March 2005
Page 3 of 43
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
4.2.1.6 The Regex and Replacement Fields...................................................................................31
4.2.2 NAPTR Examples.......................................................................................................................32
4.2.2.1 Entity Metadata NAPTR Examples.....................................................................................32
4.2.2.2 Name Identifier Examples...................................................................................................32
4.2.3 Resolution...................................................................................................................................32
4.2.3.1 Parsing the Unique Identifier...............................................................................................32
4.2.3.2 Obtaining Metadata via the DNS.........................................................................................33
4.2.4 Metadata Location Caching........................................................................................................33
4.3 Post-Processing of Metadata.............................................................................................................33
4.3.1 Metadata Instance Caching........................................................................................................33
4.3.2 Handling of HTTPS Redirects....................................................................................................33
4.3.3 Processing of XML Signatures and General Trust Processing..................................................33
4.3.3.1 Processing Signed DNS Zones...........................................................................................34
4.3.3.2 Processing Signed Documents and Fragments..................................................................34
4.3.3.3 Processing Server Authentication during Metadata Retrieval via TLS/SSL........................34
5 References................................................................................................................................................35
Appendix A.Registration of MIME media type application/samlmetadata+xml............................................37
Appendix B. Acknowledgments....................................................................................................................41
Appendix C. Notices.....................................................................................................................................43
saml-metadata-2.0-os
Copyright © OASIS Open 2005 All Rights Reserved.
15 March 2005
Page 4 of 43
1 Introduction
SAML profiles require agreements between system entities regarding identifiers, binding support and
endpoints, certificates and keys, and so forth. A metadata specification is useful for describing this
information in a standardized way. This specification defines an extensible metadata format for SAML
system entities, organized by roles that reflect SAML profiles. Such roles include that of SSO Identity
Provider, SSO Service Provider, Affiliation, Attribute Authority, Attribute Requester, and Policy Decision
Point.
This specification further defines profiles for the dynamic exchange of metadata among system entities,
which may be useful in some deployments.
The SAML conformance document [SAMLConform] lists all of the specifications that comprise SAML
V2.0.
1.1 Notation
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD
NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this specification are to be interpreted as
described in IETF RFC 2119 [RFC2119].
Listings of productions or other normative code appear like this.
Example code listings appear like this.
Note: Notes like this are sometimes used to highlight non-normative commentary.
Conventional XML namespace prefixes are used throughout this specification to stand for their respective
namespaces as follows, whether or not a namespace declaration is present in the example:
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
Prefix
saml:
samlp:
md:
ds:
xenc:
xs:
XML Namespace
Comments
urn:oasis:names:tc:SAML:2.0:assertion
urn:oasis:names:tc:SAML:2.0:protocol
urn:oasis:names:tc:SAML:2.0:metadata
This is the SAML V2.0 assertion namespace [SAMLCore].
The prefix is generally elided in mentions of SAML
assertion-related elements in text.
This is the SAML V2.0 protocol namespace [SAMLCore].
The prefix is generally elided in mentions of XML protocol-
related elements in text.
This is the SAML V2.0 metadata namespace, defined in a
schema [SAMLMeta-xsd].
http://www.w3.org/2000/09/xmldsig#
This is the XML Signature namespace [XMLSig].
http://www.w3.org/2001/04/xmlenc#
This is the XML Encryption namespace [XMLEnc].
http://www.w3.org/2001/XMLSchema
This namespace is defined in the W3C XML Schema
specification [Schema1]. In schema listings, this is the
default namespace and no prefix is shown. For clarity, the
prefix is generally shown in specification text when XML
Schema-related constructs are mentioned.
saml-metadata-2.0-os
Copyright © OASIS Open 2005 All Rights Reserved.
15 March 2005
Page 5 of 43
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
2 Metadata for SAML V2.0
SAML metadata is organized around an extensible collection of roles representing common combinations
of SAML protocols and profiles supported by system entities. Each role is described by an element derived
from the extensible base type of RoleDescriptor. Such descriptors are in turn collected into the
container element, the primary unit of SAML metadata. An entity might
alternatively represent an affiliation of other entities, such as an affiliation of service providers. The
is provided for this purpose.
Such descriptors may in turn be aggregated into nested groups using the
element.
A variety of security mechanisms for establishing the trustworthiness of metadata can be supported,
particularly with the ability to individually sign most of the elements defined in this specification.
Note that when elements with a parent/child relationship contain common attributes, such as caching or
expiration information, the parent element takes precedence (see also Section 4.3.1).
Note: As a general matter, SAML metadata is not to be taken as an authoritative
statement about the capabilities or options of a given system entity. That is, while it should
be accurate, it need not be exhaustive. The omission of a particular option does not imply
that it is or is not unsupported, merely that it is not claimed. As an example, a SAML
attribute authority might support any number of attributes not named in an
. Omissions might reflect privacy or any number
of other considerations. Conversely, indicating support for a given attribute does not imply
that a given requester can or will receive it.
2.1 Namespaces
SAML Metadata uses the following namespace (defined in a schema [SAMLMeta-xsd]):
urn:oasis:names:tc:SAML:2.0:metadata
This specification uses the namespace prefix md: to refer to the namespace above.
The following schema fragment illustrates the use of namespaces in SAML metadata documents:
saml-metadata-2.0-os
Copyright © OASIS Open 2005 All Rights Reserved.
15 March 2005
Page 6 of 43
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
Document identifier: saml-schema-metadata-2.0
Location: http://docs.oasis-open.org/security/saml/v2.0/
Revision history:
V2.0 (March, 2005):
Schema for SAML metadata, first published in SAML 2.0.
…
2.2 Common Types
The SAML V2.0 Metadata specification defines several types as described in the following subsections.
These types are used in defining SAML V2.0 Metadata elements and attributes.
2.2.1 Simple Type entityIDType
The simple type entityIDType restricts the XML schema data type anyURI to a maximum length of 1024
characters. entityIDType is used as a unique identifier for SAML entities. See also Section 8.3.6 of
[SAMLCore]. An identifier of this type MUST be unique across all entities that interact within a given
deployment. The use of a URI and holding to the rule that a single URI MUST NOT refer to different
entities satisfies this requirement.
The following schema fragment defines the entityIDType simple type:
2.2.2 Complex Type EndpointType
The complex type EndpointType describes a SAML protocol binding endpoint at which a SAML entity can
be sent protocol messages. Various protocol or profile-specific metadata elements are bound to this type.
It consists of the following attributes:
Binding [Required]
A required attribute that specifies the SAML binding supported by the endpoint. Each binding is
assigned a URI to identify it.
Location [Required]
A required URI attribute that specifies the location of the endpoint. The allowable syntax of this
URI depends on the protocol binding.
ResponseLocation [Optional]
Optionally specifies a different location to which response messages sent as part of the protocol
or profile should be sent. The allowable syntax of this URI depends on the protocol binding.
The ResponseLocation attribute is used to enable different endpoints to be specified for receiving
request and response messages associated with a protocol or profile, not as a means of load-balancing or
redundancy (multiple elements of this type can be included for this purpose). When a role contains an
element of this type pertaining to a protocol or profile for which only a single type of message (request or
response) is applicable, then the ResponseLocation attribute is unused.
In most contexts, elements of this type appear in unbounded sequences in the schema. This is to permit a
protocol or profile to be offered by an entity at multiple endpoints, usually with different protocol bindings,
allowing the metadata consumer to choose an appropriate endpoint for its needs. Multiple endpoints might
saml-metadata-2.0-os
Copyright © OASIS Open 2005 All Rights Reserved.
15 March 2005
Page 7 of 43
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
also offer "client-side" load-balancing or failover, particular in the case of a synchronous protocol binding.
This element also permits the use of arbitrary elements and attributes defined in a non-SAML namespace.
Any such content MUST be namespace-qualified.
The following schema fragment defines the EndpointType complex type:
maxOccurs="unbounded"/>
2.2.3 Complex Type IndexedEndpointType
The complex type IndexedEndpointType extends EndpointType with a pair of attributes to permit the
indexing of otherwise identical endpoints so that they can be referenced by protocol messages. It consists
of the following additional attributes:
index [Required]
A required attribute that assigns a unique integer value to the endpoint so that it can be
referenced in a protocol message. The index value need only be unique within a collection of like
elements contained within the same parent element (i.e., they need not be unique across the
entire instance).
isDefault [Optional]
An optional boolean attribute used to designate the default endpoint among an indexed set. If
omitted, the value is assumed to be false.
In any such sequence of like endpoints based on this type, the default endpoint is the first such endpoint
with the isDefault attribute set to true. If no such endpoints exist, the default endpoint is the first such
endpoint without the isDefault attribute set to false. If no such endpoints exist, the default endpoint is
the first element in the sequence.
The following schema fragment defines the IndexedEndpointType complex type:
2.2.4 Complex Type localizedNameType
The localizedNameType complex type extends a string-valued element with a standard XML language
attribute. The following schema fragment defines the localizedNameType complex type:
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
