OASIS Service Provisioning Markup Language (SPML) V2 - SAML 2.0Profile

OASIS Service Provisioning Markup Language (SPML) v2 - SAML 2.0Profile

OASIS Standard
2006April 1

Document identifier: pstc-spml2-saml-profile-os.pdf

Location:

Send comments to:

Editor:

Jeff Bohren, BMC ()

Contributors:

Richard Sand, Tripod Technology Group

Blaine Busler, Tripod Technology Group

Robert Boucher, CA

Doron Cohen, BMC

Gary Cole, Sun Microsystems

Cal Collingham, CA

Rami Elron, BMC

Marco Fanti, Thor Technologies

Ian Glazer, IBM

James Hu, HP

Ron Jacobsen, CA

Jeff Larson, Sun Microsystems

Hal Lockhart, BEA

Prateek Mishra, Oracle Corporation

Martin Raepple, SAP

Darran Rolls, Sun Microsystems

Kent Spaulding, Sun Microsystems

Gavenraj Sodhi, CA

Cory Williams, IBM

Gerry Woods, SOA Software

Abstract:

This specification defines usage of SAML 2.0 as a data model (profile) for SPML v2.

Status:

This is an OASIS Standard document produced by the Provisioning Services Technical Committee. It was approved by the OASIS membership on 1 April 2006.

If you are on the provision list for committee members, send comments there. If you are not on that list, subscribe to the list and send comments there. To subscribe, send an email message to with the word "subscribe" as the body of the message.

Copyright (C) OASIS Open 2006. All Rights Reserved.
Table of contents

1.Introduction (non-normative)

1.1.Concepts

1.1.1.SAML Protocol

1.2.Terminology

2.Notation

3.Overview (non-normative)

3.1.SAML PSOs

3.1.1.PSO Identifier

3.1.2.PSO Data

3.2.Schema

3.3.Core Operations

3.3.1.Add Request

3.3.2.Add Response

3.3.3.Modify Request

3.3.4.Modify Response

3.3.5.Delete Request

3.3.6.Lookup Request

3.3.7.Lookup Response

3.4.Search Operations

3.4.1.Search Request

3.4.2.Search Response

4.Specification (Normative)

4.1.Namespaces

4.2.Core Capability

4.2.1.Element <spml:data>

4.2.2.Element <spml:modification>

4.2.3.Element <spml:schema>

4.2.4.Element <spml:supportedSchemaEntity>

4.3.Search Capability

4.3.1.Element <spmlsearch:query>

4.4.SAML Profile Schema

Appendix A. References

Appendix B. Acknowledgments

Appendix C. Notices

1.Introduction (non-normative)

1.1.Concepts

SPML Version 2 (SPMLv2) defines a core protocol [SPMLv2] over which different data models can be used to define the actual provisioning data. The combination of a data model with the SPML core specification is referred to as a profile. The use of SPML requires that a specific profile is used, although the choice of which profile is used to negatioted out-of-band by the participating parties.

This document describes the use of the SAML protocol as a data model for SPML based provisioning. This profile is optional.

1.1.1.SAMLProtocol

The SAML 2.0 protocol [***SAMLv2?] defines the syntax and processing semantics of

assertions made about a subject by a system entity. ***Say some more here??

1.2.Terminology

Within this document:
- The term “requestor” always refers to a Requesting Authority (RA).
- The term “provider” always refers to a Provisioning Service Provider (PSP).
- The term “target” always refers to a Provisioning Service Target (PST).
- The term “object” (unless otherwise qualified) refers to a Provisioning Service Object (PSO).
- The term “client” (unless otherwise qualified) refers to a Requesting Authority (RA).
- The term “server” (unless otherwise qualified) refers to a Provisioning Service Provider (PSP).

2.Notation

This specification contains schema conforming to W3C XML Schema and normative text to describe the syntax and semantics of XML-encoded policy statements.

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]

"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.

This specification uses the following typographical conventions in text:

Terms in italic bold-face are intended to have the meaning defined in the Glossary.

Listings of SPML schemas appear like this.

Example code listings appear like this.

Conventional XML namespace prefixes are used throughout the listings in this specification to stand for their respective namespaces as follows, whether or not a namespace declaration is present in the example:
- The prefix saml: stands for the SAML assertion namespace [SAML].
- The prefix ds: stands for the W3C XML Signature namespace [DS].
- The prefix xsd: stands for the W3C XML Schema namespace [XS].

3.Overview (non-normative)

3.1.SAML PSOs

A PSO is represented in this binding by a SAML Attribute Assertion that is associated with a target-unique SAML identifier.

The SAML Attribute Assertions are used to provide identity and attribute data for a Provisioning Service Object. The PSO is equivalent to a SAML Subject in this regard.

3.1.1.PSO Identifier

***Investigate whether we can legally extend psoID to include an additional attribute to specify the type of the PSO Identifier. If not, it will be up to the PSP to determine by analysis what type of ID is being used.

The PSO Identifier may be one of several types of SAML NameIDidentifiers. However, not every identifier specified in SAML is allowed as an identifier for a PSO. The following SAML name identifiers are allowed:

• Unspecified

URI: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

The interpretation of the content of the element is left to individual implementations.

• E-Mail address

URI: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Indicates that the content of the element is in the form of an email address, specifically "addr-spec" as defined in IETF RFC 2822 [RFC 2822] Section 3.4.1. An addr-spec has the form local-part@domain. Note that an addr-spec has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">".

• X509 Subject Name

URI: urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName

Indicates that the content of the element is in the form specified for the contents of the<ds:X509SubjectName> element in the XML Signature Recommendation [XMLSig]. Implementorsshould note that the XML Signature specification specifies encoding rules for X.509 subject names thatdiffer from the rules given in IETF RFC 2253 [RFC 2253].

***Do we need additional meta-data attributes to allow the RA to “recommend” to the PSP how to extract a user id from the subject? Especially if its provided as part of an add request…

• WindowsDomainQualifiedname

URI: urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName

Indicates that the content of the element is a Windows domain qualified name. A Windows domainqualified user name is a string of the form "DomainName\UserName". The domain name and "\" separatorMAY be omitted.

• Kerberos

URI: urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos

Indicates that the content of the element is in the form of a Kerberos principal name using the formatname[/instance]@REALM. The syntax, format and characters allowed for the name, instance, andrealm are described in IETF RFC 1510 [RFC 1510].

Below is an example of a psoID using a SAML X509 NameIdentifier.Is this legal to do, include the saml identifier within a PSOIdentifierType? PSOIdentifierType extends IdentifierType which extends ExtensibleType, so this should be ok. Confirmations welcome!

spml:psoxmlns:spml="urn:oasis:names:tc:SPML:2:0" xmlns:saml="urn:oasis:names:tc:SAML:2.0"

<spml:psoID targetID="acme.com"

<saml:NameIdentifier>cn=John Doe,dc=acme,dc=com</saml:NameIdentifier>

</spml:psoID>

</spml:pso>

3.1.2.PSO Data

The PSO Data element contains SAML Attribute Assertions, as defined in [SAML]. Additional data may be included via the Open Content Model.

<spml:psoxmlns:spml="urn:oasis:names:tc:SPML:2:0" xmlns:saml="urn:oasis:names:tc:SAML:2.0"

<spml:data>

<saml:Attribute AttributeName="Email">

<saml:AttributeValue></saml:AttributeValue>

</saml:Attribute>

</spml:data>

</spml:pso>

3.2.Schema

***How do we handle schema with SAML?

3.3.Core Operations

3.3.1.Add Request

The Add Request creates PSOs. The Add Request must contain a <data> element that contains SAML 2.0Attribute> elements that define the new PSO. The Add Request may also pass a PSO Identifier (<psoID> element), a container PSO ID (<containerID> element), or a target ID (<targetID> element). If a PSO identifier is not defined in the Add Request, the new PSO Identifier must be returned in the Add Response.

<spml:addRequestxmlns:spml="urn:oasis:names:tc:SPML:2:0" xmlns:saml="urn:oasis:names:tc:SAML:2.0"

<spml:containerID ID="OU=accounting,DC=acme.com" targetID="acme.com"/>

<spml:data>

<saml:Attribute AttributeName="FirstName">

<saml:AttributeValue>John</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="LastName">

<saml:AttributeValue>Doe</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="Email">

<saml:AttributeValue></saml:AttributeValue>

</saml:Attribute>

</spml:data>

</spml:addRequest

3.3.2.Add Response

The Add Response message must contain the new PSO ID (unless it was specified in the Add Request). If the creation of the new PSO resulted in attributes being adding or modified in the new PSO, the entire PSO Data should be returned in the response.

<spml:addResponse status="spml:success"xmlns:spml="urn:oasis:names:tc:SPML:2:0" xmlns:saml="urn:oasis:names:tc:SAML:2.0"

<spml:psoID targetID="acme.com"

<saml:NameIdentifier>cn=John Doe,dc=acme,dc=com</saml:NameIdentifier>

</spml:psoID>

<spml:data>

<saml:Attribute AttributeName="FirstName">

<saml:AttributeValue>John</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="LastName">

<saml:AttributeValue>Doe</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="Email">

<saml:AttributeValue></saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="FullName">

<saml:AttributeValue>John Doe</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="LogonID">

<saml:AttributeValue>jdoe</saml:AttributeValue>

</saml:Attribute>

</spml:data>

</spml:addResponse>

3.3.3.Modify Request

The Modify Request modifies thespecified PSO. The Modify Request must contain the PSO Identifier.

***We must define behavior for modifying multi-valued attributes. When the modificationModeof the spml modify request is 'delete' or 'modify' it would normally apply to all values of an attribute. Consider what issues are involved with adding the ability to specify that a single value be replaced or deleted instead of all values in the attribute.

<spml:modifyRequest xmlns:spml="urn:oasis:names:tc:SPML:2:0" xmlns:saml="urn:oasis:names:tc:SAML:2.0"

<spml:psoID targetID="acme.com">

<saml:NameIdentifier>cn=John Doe,dc=acme,dc=com</saml:NameIdentifier>

</spml:psoID>

<spml:modification>

<saml:Attribute AttributeName="FirstName">

<saml:AttributeValue>Jane</saml:AttributeValue>

</saml:Attribute>

</spml:modification>

</spml:modifyRequest >

3.3.4.Modify Response

If the Modify Request causes the PSO ID to change, then the Modify Response must contain the new PSO ID.

<spml:modifyResponse status="spml:success"xmlns:spml="urn:oasis:names:tc:SPML:2:0" xmlns:saml="urn:oasis:names:tc:SAML:2.0"

<spml:psoID targetID="acme.com">

<saml:NameIdentifier>cn=Jane Doe,dc=acme,dc=com</saml:NameIdentifier>

</spml:psoID>

</spml:modifyResponse>

3.3.5.Delete Request

The Delete Request deletes a specified PSO.

<spml:deleteRequest xmlns:spml="urn:oasis:names:tc:SPML:2:0" xmlns:saml="urn:oasis:names:tc:SAML:2.0"

<spml:psoID targetID="acme.com">

<saml:NameIdentifier>cn=John Doe,dc=acme,dc=com</saml:NameIdentifier>

</spml:psoID>

</spml:deleteRequest

3.3.6.Lookup Request

The Lookup Request is used to retrieve the data for a specified PSO.

<spml:lookupRequest xmlns:spml="urn:oasis:names:tc:SPML:2:0" xmlns:saml="urn:oasis:names:tc:SAML:2.0"

<spml:psoID targetID="acme.com">

<saml:NameIdentifier>cn=John Doe,dc=acme,dc=com</saml:NameIdentifier>

</spml:psoID>

</spml:lookupRequest>

3.3.7.Lookup Response

The Lookup Response contains the retrieved PSO data.

<spml:lookupResponse status="spml:success" xmlns:spml="urn:oasis:names:tc:SPML:2:0" xmlns:saml="urn:oasis:names:tc:SAML:2.0"

<spml:psoID targetID="acme.com">

<saml:NameIdentifier>cn=John Doe,dc=acme,dc=com</saml:NameIdentifier>

</spml:psoID>

<spml:data>

<saml:Attribute AttributeName="FirstName">

<saml:AttributeValue>John</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="LastName">

<saml:AttributeValue>Doe</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="Email">

<saml:AttributeValue></saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="FullName">

<saml:AttributeValue>John Doe</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="LogonID">

<saml:AttributeValue>jdoe</saml:AttributeValue>

</saml:Attribute>

</spml:data>

</spml:lookupResponse>

3.4.Search Operations

We have defined a custom search XML syntax which can be combined with the SPML LogicalOperatorType search elements and, or, not

***Detail all operations

3.4.1.Search Request

The search request can specify SAML filters and attribute declarations.

***How to handle search base “basePSOID”? The spec does say minoccur = 0.

Also, should the server just ignore “scope” if its not applicable i.e. if the PST is not a hierarchy?

spmlsearch:searchRequest xmlns:spml="urn:oasis:names:tc:SPML:2:0"xmlns:spmlsearch="urn:oasis:names:tc:SPML:2:0:search" xmlns:saml="urn:oasis:names:tc:SAML:2.0" xmlns:spmlsaml="urn:oasis:names:tc:SPML:2:0:SAML"

<spmlsearch:query scope="spmlsearch:subTree">

<spmlsaml:queryElement type="equals" multi="any"

<saml:Attribute AttributeName="FirstName">

<saml:AttributeValue>John</saml:AttributeValue>

</saml:Attribute>

</spmlsaml:queryElement>

<spml:and/>

<spmlsaml:queryElement type="contains" multi="all"

<saml:Attribute AttributeName="EmployeeType">

<saml:AttributeValue>contractor</saml:AttributeValue>

</saml:Attribute>

</spmlsaml:queryElement>

<spml:and/>

<spmlsaml:queryElement type="equalsIgnoreCase" multi="all"

<saml:Attribute AttributeName="Role">

<saml:AttributeValue>human resources</saml:AttributeValue>

<saml:AttributeValue>benefits</saml:AttributeValue>

</saml:Attribute>

</spmlsaml:queryElement>

</spmlsearch:query>

</spmlsearch:searchRequest>

“Type” means the comparison type to perform. Possible values are: “equals”, “equalsIgnoreCase”, “contains” (like doing *<value>*), “greaterThan”, “lessThan”

“Multi” means how to handle multi-valued attribute matching. “All” means that all provided values must match all of the values at the PST. “Any” means that each provided value must match any one value at the PST (but the attribute can also have other values at the PST). If not specified, the default is “any”. ***Specify default and specify which option must be supported for a PSP to be compliant

Regarding use of the and/or/not SPML elements, they can be used self-contained i.e. <spml:and/> or they can contain spmlsaml i.e. <spml:not<spmlsaml:queryElement….</spml:not>. ***Confirm this is legal by the spml search XSD

3.4.2.Search Response

spmlsearch:searchResponse status="spml:success"xmlns:spml="urn:oasis:names:tc:SPML:2:0"xmlns:spmlsearch="urn:oasis:names:tc:SPML:2:0:search" xmlns:saml="urn:oasis:names:tc:SAML:2.0"

<spml:pso>

<spml:psoID targetID="acme.com">

<saml:NameIdentifier>cn=John Doe,dc=acme,dc=com</saml:NameIdentifier>

</spml:psoID>

<spml:data>

<saml:Attribute AttributeName="Email">

<saml:AttributeValue></saml:AttributeValue>

</saml:Attribute>

</spml:data>

</spml:pso>

spml:pso>

<spml:psoID targetID="acme.com">

<saml:NameIdentifier>cn=John Smith,dc=acme,dc=com</saml:NameIdentifier>

</spml:psoID>

<spml:data>

<saml:Attribute AttributeName="Email">

<saml:AttributeValue></saml:AttributeValue>

</saml:Attribute>

</spml:data>

</spml:pso>

</spmlsearch:searchResponse>

4.Specification (Normative)

4.1.Namespaces

The SAMLv2 Profile uses the SAML 2.0 namespace which is defined as:

urn:oasis:names:tc:SAML:2.0

The specification uses the prefix saml: to refer to this namespace.

The SAMLv2 Profile defines some elements that are specific to the profile. The namespace for the profile itself is defined as:

urn:oasis:names:tc:SPML:2:0:SAML

The specification uses the prefix spmlsaml: to refer to this namespace.

4.2.Core Capability

4.2.1.Element <spml:data

The spml:data> element MUST contain zero or many SAML:Attribute elements.

4.2.2.Element <spml:modification

The spml:modification> element MUST contain zero or many SAML:Attribute elements. The “modificationType” on the spml:modification> MUST be specified.

4.2.3.Element <spml:schema>

***To be completed

4.2.4.Element <spml:supportedSchemaEntity

The “entityName” attribute on the spml:supportedSchemaEntity>element MUST refer only to object classes defined in the referenced schema. All attributes on the referenced object classes are assumed to be supported. ***How this applies will depend on how we handle object classes in SAML??

4.3.Search Capability

4.3.1.Element <spmlsearch:query>

***To be completed

4.4.SAML Profile Schema

***Need to define spmlsaml XSD

Appendix A.References

[AES]National Institute of Standards and Technology (NIST), FIPS-197: Advanced Encryption Standard, http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf, National Institute of Standards and Technology (NIST)

[ARCHIVE-1]OASIS Provisioning Services Technical Committee, email archive, , OASIS PS-TC

[DS]IETF/W3C, W3C XML Signatures, , W3C/IETF

[GLOSSARY]OASIS Provisioning Services TC, Glossary of Terms, , OASIS PS-TC