TOC 
 P. Madsen, Ed.
Internet-DraftPing Identity Corp.
Intended status: Standards TrackApril 2011
Expires: October 3, 2011 


SAML 2.0 Binding for SCIM
draft-scim-saml2-binding-01

Abstract

This specification defines a binding of the Simple Cloud Identity Management (SCIM) schema to the Security Assertion Markup Language (SAML).

Status of this Memo

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.



Table of Contents

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 

1.  Introduction

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 

1.1.  Notational Conventions

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 

2.  Binding to SAML

Binding SCIM to SAML SSO involves the following aspects:



 TOC 

2.1.  Mapping SCIM user attributes into SAML attributes

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



SCIMSAMLNotes
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  
email 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 

2.1.1.  Supporting multi-value SCIM elements

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 

2.2.  Using SAML SSO Assertion attributes to carry SCIM user attributes

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 

2.3.  Using SAML AttributeQuery to retrieve SCIM user attributes

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 

2.4.  Using SAML metadata to advertise supported/desired SCIM attributes

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 

3.  Security Considerations

TBD



 TOC 

Appendix A.  Document History

draft-scim-saml2-binding-01

draft-scim-saml2-binding-01



 TOC 

4. Normative References

[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 

Author's Address

  Paul Madsen (editor)
  Ping Identity Corp.
Email:  pmadsen@pingidentity.com


 TOC 

Full Copyright Statement

Intellectual Property