idnits 2.17.00 (12 Aug 2021) /tmp/idnits17253/draft-guenther-saml-policy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 307. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 2005) is 6305 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-common-policy - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-geopriv-common-policy' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAML' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Geopriv C. Guenther 2 Internet-Draft Siemens 3 Expires: August 17, 2005 February 13, 2005 5 SAML in Authorization Policies 6 draft-guenther-saml-policy-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 17, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 Rules of an authorization policy prescribe under which conditions an 42 entity or subject has which permissions. Existing policies support 43 identity-based authorization by matching the authenticated identity 44 of the entity requesting access to a resource with the available 45 policies. This document is about formulating policy rules that 46 express conditions with respect to SAML assertions, thereby 47 supporting non-identity-based authorization and anonymity. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Basic Scenario . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. SAML Conditions Example . . . . . . . . . . . . . . . . . . 6 55 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 6. Security Considerations . . . . . . . . . . . . . . . . . . 9 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 58 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 11 59 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 61 Intellectual Property and Copyright Statements . . . . . . . 13 63 1. Introduction 65 The Security Assertion Markup Language, see [SAML], is an XML 66 sublanguage for exchanging security information. It is suitable for 67 expressing assertions concerning previously performed authentication 68 procedures and authorization decisions. For example, a SAML 69 assertion can be used by the assertion issuer to assure that the 70 assertion subject (e.g., a person, a network entity, ...) has been 71 authenticated by means of a specific authentication method M. A 72 recipient of such an assertion - if it has trust in the assertion 73 issuer and the integrity of the assertion - can then base its 74 authorization decisions on this assertion. 76 This document is about defining an extension to the Common Policy 77 markup language, see [I-D.ietf-geopriv-common-policy], that allows to 78 express conditions with respect to statements contained in SAML 79 assertions. It shall be possible to express authorization policy 80 rules of the following fashion: If the SAML assertion has been issued 81 by the assertion issuer A and if the assertion assures that the 82 assertion subject S has been authenticated by means of the 83 authenticated method M, then S is permitted to ... . 85 2. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 3. Basic Scenario 93 Figure 1 depicts a basic scenario in the scope of this document: a 94 Subject S wishes to have access to a certain resource (e.g., location 95 information of a particular entity). After a successful 96 authentication protocol execution between S and the Asserting Party 97 (AP), see step 1, the AP issues a SAML assertion (step 2), which 98 asserts that S has been authenticated by AP using method M and is 99 associated with a certain set of attributes. 101 +-------------+ 1: Authentication +------------+ 102 | |<----------------->| Asserting | 103 | Subject S | | Party | 104 | |<------------------| (AP) | 105 +-------------+ 2: SAML Assertion +------------+ 106 | 107 | 108 3:| Service Request 109 | + Assertion 110 v 111 +-------------+ +------------+ 112 | Relying | 4: Policy | Policy | 113 | Party |<------------------| Server | 114 | (RP) | | (PS) | 115 +-------------+ +------------+ 117 Figure 1: Basic Scenario 119 After receipt of the assertion, the Relying Party (RP) can base its 120 resource access authorization decision on this assertion. The 121 authorization policy governing access to the requested resource is 122 stored at the Policy Server (PS). Thanks to the language elements 123 introduced in this document, this policy can contain rules whose 124 conditions parts express properties that the SAML assertion must meet 125 in order to make the rule match. 127 4. SAML Conditions Example 129 This document extends the Common Policy markup language by adding new 130 elements to the substitution group defined in the schema 131 of the Common Policy markup language, see 132 [I-D.ietf-geopriv-common-policy]. This paragraph provides a basic 133 example of an XML document valid with respect to the XML schema 134 defined in Section 5. 136 137 148 150 152 153 https://www.idp.com/ 155 156 157 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 158 159 161 163 164 2005-03-06T17:00:00-05:00 165 2005-03-11T19:00:00-05:00 166 168 170 172 174 176 The rule set in this example consists of one rule only. The 177 part of the rule consists of a condition 178 (defined by the Common Policy schema) and a condition 179 which is defined by this document in Section 5. As there is no 180 subelement of , this rule matches for each 181 Subject identified in a SAML authentication assertion issued by 182 idp.com that asserts that the Subject has been authenticated through 183 the presentation of a password over a protected session (e.g., 184 protected by SSL or IPSec). 186 5. XML Schema 188 189 197 199 202 203 204 206 207 209 211 212 213 215 216 217 219 220 221 223 225 6. Security Considerations 227 [tbd] 229 7. IANA Considerations 231 [tbd] 233 8. Open Issues 235 1) There are not only authentication assertions in SAML, but also 236 authorization decision and attribute assertions. Inspect the 237 usability of these types of SAML assertions in the scope of this 238 document. 240 2) Modify and enhance the XML schema in accordance to 1). Possibly, 241 it could be more appropriate to directly adopt XML element and type 242 definitions as given in the SAML assertion schema instead of defining 243 new ones. 245 3) It could be useful to let the element represent an 246 XML schema that specizializes the SAML assertion schema with respect 247 to the target of the authorization policy. Example: Instaed of 248 listing all permitted authentication context class references in 249 , you could write down a target-specific SAML 250 assertion schema with an element whose 251 definition is completely identical to the SAML definition of 252 , except for the fact that only certain URIs 253 are permitted as values to make the SAML assertion valid with respect 254 to this specialized assertion schema. 256 4) Security considerations. 258 5) IANA considerations. 260 9. Normative References 262 [I-D.ietf-geopriv-common-policy] 263 Schulzrinne, H., Morris, J., Tschofenig, H., Polk, J. and 264 J. Rosenberg, "A Document Format for Expressing Privacy 265 Preferences", Internet-Draft draft-ietf-common-policy-03, 266 October 2004. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", March 1997. 271 [SAML] OASIS, "Assertions and Protocol for the OASIS Security 272 Assertion Markup Language (SAML) V2.0", OASIS Committee 273 Draft sstc-saml-core-2.0-cd-04.pdf, January 2005. 275 Author's Address 277 Christian Guenther 278 Siemens 279 Otto-Hahn-Ring 6 280 Munich, Bayern 81739 281 Germany 283 Email: christian.guenther@siemens.com 285 Intellectual Property Statement 287 The IETF takes no position regarding the validity or scope of any 288 Intellectual Property Rights or other rights that might be claimed to 289 pertain to the implementation or use of the technology described in 290 this document or the extent to which any license under such rights 291 might or might not be available; nor does it represent that it has 292 made any independent effort to identify any such rights. Information 293 on the procedures with respect to rights in RFC documents can be 294 found in BCP 78 and BCP 79. 296 Copies of IPR disclosures made to the IETF Secretariat and any 297 assurances of licenses to be made available, or the result of an 298 attempt made to obtain a general license or permission for the use of 299 such proprietary rights by implementers or users of this 300 specification can be obtained from the IETF on-line IPR repository at 301 http://www.ietf.org/ipr. 303 The IETF invites any interested party to bring to its attention any 304 copyrights, patents or patent applications, or other proprietary 305 rights that may cover technology that may be required to implement 306 this standard. Please address the information to the IETF at 307 ietf-ipr@ietf.org. 309 Disclaimer of Validity 311 This document and the information contained herein are provided on an 312 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 313 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 314 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 315 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 316 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 317 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 319 Copyright Statement 321 Copyright (C) The Internet Society (2005). This document is subject 322 to the rights, licenses and restrictions contained in BCP 78, and 323 except as set forth therein, the authors retain all their rights. 325 Acknowledgment 327 Funding for the RFC Editor function is currently provided by the 328 Internet Society.