TOC |
|
This specification defines a binding of the Simple Cloud Identity Management (SCIM) schema to the Security Assertion Markup Language (SAML).
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 become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on October 3, 2011.
1.
Introduction
1.1.
Notational Conventions
2.
Binding to SAML
2.1.
Mapping SCIM user attributes into SAML attributes
2.1.1.
Supporting multi-value SCIM elements
2.2.
Using SAML SSO Assertion attributes to carry SCIM user attributes
2.3.
Using SAML AttributeQuery to retrieve SCIM user attributes
2.4.
Using SAML metadata to advertise supported/desired SCIM attributes
3.
Security Considerations
Appendix A.
Document History
4.
Normative References
§
Author's Address
§
Intellectual Property and Copyright Statements
TOC |
The Simple Cloud Identity Management (SCIM) core schema (Mortimore, C., Ed., “Simple Cloud Identity Management: Core Schema 1.0 - draft 1,” April 2011.) [scim‑core] defines a platform neutral data and extension model for representing users of cloud services. SCIM core also defines XML & JSON serializations of the abstract schema. This specification defines a binding of SCIM schema to SAML (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) [OASIS.saml‑core‑2.0‑os] messages and assertions - allowing SCIM instances to be carried on SAML SSO - as defined in the SAML Web SSO profile (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) [OASIS.saml‑profiles‑2.0‑os].
Carrying user attributes on SSO messages enables a just-in-time provisioning model, whereby a user's attributes are provided to the cloud service only at time of first access - rather than a priori. This can greatly simplify the integration work required in scenarios where users need to be dynamically provisioned, by combining the account creation and single sign-on processes into a single message.
TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
TOC |
Binding SCIM to SAML SSO involves the following aspects:
TOC |
This section defines a a mapping between SCIM schema elements (and associated attributes) and SAML attributes - the value of the SCIM schema element becoming the value of the SAML attribute.
All SCIM-derived SAML attributes are of type 'xs:string'.
To do: explore defning an actual SAML attribute profile
SCIM | SAML | Notes |
---|---|---|
id | SCIM.id | |
externalId | SCIM.externalId | Can't update, insert only |
userName | SCIM.userName | |
name/formatted | SCIM.name.formatted | |
name/familyName | SCIM.name.familyName | |
name/givenName | SCIM.name.givenName | |
name/middleName | SCIM.name.middleName | |
name/honorificPrefix | SCIM.name.honorificPrefix | |
name/honorificSuffix | SCIM.name.honorificSuffix | |
displayName | SCIM.displayName | |
nickName | SCIM.nickName | |
profileUrl | SCIM.profileUrl | |
employeeNumber | SCIM.employeeNumber | |
userType | SCIM.userType | |
title | SCIM.title | |
manager | SCIM.manager | |
preferredLanguage | SCIM.preferredLanguage | |
locale | SCIM.locale | |
utcOffset | SCIM.utcOffset | |
costCenter | SCIM.costCenter | |
organization | SCIM.organization | |
division | SCIM.division | |
department | SCIM.department | |
SCIM.email | multi | |
phoneNumber | SCIM.phoneNumber | multi |
im | SCIM.im | multi |
photo | SCIM.photo | multi |
address | SCIM.address | multi |
address/formatted | SCIM.address.formatted | |
address/streetAddress | SCIM.address.streetAddress | |
address/locality | SCIM.address.locality | |
address/region | SCIM.address.region | |
address/postalCode | SCIM.address.postalCode | |
address/country | SCIM.address.country | |
group | SCIM.group | multi |
Table 1: SCIM to SAML Mapping |
TOC |
The SCIM core schema supports multi-value elements for emails, addresses etc. SCIM allows individual occurrences of such elements to be categorized by 'type' and 'primary'.
In order to express 'type' and 'primary' on SAML attributes - the corresponding SAML attributes MAY be extended with corresponding XML attributes in a SCIM XML namespace qualified with "http://placeholder.scim.org/2011/schema/extension"
For example:
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="SCIM.email"> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string" scim:type="home" scim:primary="true"> dwight@schrute.org </saml:AttributeValue> </saml:Attribute>
Figure 1: Example extension |
When a multi-valued SCIM element has child-elements (e.g. address has streetAddress, postalCode, etc), if the 'type' and 'primary' are set on the parent, the 'type' and 'primary' XML attributes MUST be added to each SAML attribute corresponding to the children.
Follows is an example of a set of SCIM attributes expressed in SAML
<saml:AttributeStatement xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:scim="http://placeholder.scim.org/2011/schema/extension"> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="SCIM.userName"> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">dschrute@example.com</saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="SCIM.name.formatted"> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Mr. Dwight K Schrute III</saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="SCIM.photo"> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string" scim:type="work" scim:primary="true"> https://photos.example.com/profilephoto/72930000000Ccne/F</saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="SCIM.address.formatted"> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string" scim:type="work" scim:primary="true"> 100 Universal City Plaza\nHollywood, CA 91608 USA </saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="SCIM.address.streetAddress"> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string" scim:type="work" scim:primary="true"> 100 Universal City Plaza </saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="SCIM.address.formatted"> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string" scim:type="home"> 456 Hollywood Blvd\nHollywood, CA 91608 USA </saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="SCIM.address.streetAddress"> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string" scim:type="home"> 456 Hollywood Blvd </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement>
Figure 2: Example of SAML Attributes carrying SCIM info |
TOC |
An IdP MAY embed SCIM attributes in SAML Attributes within a SAML SSO Assertion - as per the above mapping.
The SAML SSO Assertion binding can be used to both create a new account at the Service Provider (in which case the Service Provider will not have previously seen the SCIM externalId or userName), or to update an existing account (in which case an account for the corresponding user will already exist.
If the Service Provider determines that it already has an account for a user identified by the SCIM.id attribute, it MUST update all associated SCIM elements with the values of the corresponding SAML attributes. For those SAML attributes in the SSO Assertion for which the Service Provider does not have a corresponding SCIM element, it MUST create a new SCIM element with the value of the SAML Attribute.
TOC |
An SP can use the SAML AttributeQuery to retrieve SCIM user attributes from the IdP, rather than having them delivered directly in the SAML SSO Assertion.
If the AttributeQuery is initiated by reception of an SSO assertion, the SP MUST use the value of the NameId within that assertion as the value of the NameID within the AttributeQuery to the IdP.
If not initiated by an SSO assertion, the SP SHOULD use the SCIM.id attribute, or the SCIM.externalId attribute if present, as the value of the NameID.
The SP MAY specify desired attributes in the AttributeQuery.
Shown below is an example SAML AttributeQuery
<samlp:AttributeQuery xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="aaf23196-1773-2113-474a-fe114412ab72" Version="2.0" IssueInstant="2006-07-17T20:31:40Z"> <saml:Issuer> serviceconsumer.com </saml:Issuer> <saml:Subject> <saml:NameID NameQualifier="idp.com" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"> 701984 </saml:NameID> </saml:Subject> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="SCIM.address.streetAddress"> </saml:Attribute> </samlp:AttributeQuery>
Figure 3: Example AttributeQuery |
TOC |
The SAML Metadata specification [SAMLMeta] defines a means for information about SAML entities to be represented and communicated securely. This section defines how the SCIM attributes an cloud provider requrires/supports can be expressed in a SAML metadata instance so that enterprises can know to supply them.
A SCIM Service Provider MAY indicate to a Service Consumers the SCIM elements it expects in SAML SSO assertions using the RequestedAttribute element in the AssertionConsumingService element of its SAML metadata SPSSODescriptor.
Shown below is an example SAML SPSSODescriptor.
<md:SPSSODescriptor> <md:AttributeConsumingService index="1" isDefault="true"> <md:ServiceName xml:lang="en"> Cloudz 'R' Us </md:ServiceName> <md:RequestedAttribute name="SCIM.email" isRequired="true"></md:RequestedAttribute> <md:RequestedAttribute name="SCIM.address" isRequired="true"></md:RequestedAttribute> </md:AttributeConsumingService> </md:SPSSODescriptor>
Figure 4: Example metadata |
TOC |
TBD
TOC |
draft-scim-saml2-binding-01
draft-scim-saml2-binding-01
TOC |
[OASIS.saml-core-2.0-os] | Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-core-2.0-os, March 2005. |
[OASIS.saml-profiles-2.0-os] | Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard OASIS.saml-profiles-2.0-os, March 2005. |
[RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
[scim-core] | Mortimore, C., Ed., “Simple Cloud Identity Management: Core Schema 1.0 - draft 1,” April 2011. |
TOC |
Paul Madsen (editor) | |
Ping Identity Corp. | |
Email: | pmadsen@pingidentity.com |
TOC |
Copyright © The IETF Trust (2011).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.