ࡱ > ` Q bjbjss . I ^b ^b ^b ^b l b h bc bc bc bc bc bc bc bc c e e e e e e $ L h f bc bc bc bc bc bc bc bc bc bc c bc c ǃ bc Vc ``| ^b s ߃ c 0 , } bc bc bc bc bc bc bc Ҁ bc bc bc bc bc bc bc $8 = d$ = SAML 2.0 Profile of SPML 2.0 Submission
Submitting Organizations
AOL
BMC Software
HP
Intel
Neustar
Sun Microsystems
Tripod Technology Group
Introduction
This document describes a submission to the OASIS Security Services Technical Committee for a new SAML 2.0 Profile of SPML 2.0 for federated provisioning. The Federated Provisioning Profile is designed to support the Bulk Provisioning use case where an Identity Management Lifecycle exists between the IdP and SP.
The proposed profile will use the OASIS Service Provisioning Markup Language (SPML) 2.0 standard as the provisioning protocol with elements from the SAML 2.0 Assertion schema as the provisioning data.
For the purposes of this submission, the examples are given in terms of the IdP making provisioning requests to the SP. There are valid use cases for the SP to make provisioning requests to the IdP, but there are no examples of this in this submission, as they would be redundant and would add no additional insight.
Overview
Provisioning Data
Object Identifiers
All objects used in SPML 2.0 must have an identifier that is unique within the namespace of the provisioning service. This is known as the Provisioning Service Object ID (PSO ID). The format of the PSO ID is profile-specific. For the SAML 2.0 Federated Provisioning Profile, the SAML 2.0 NameIdentifier element is used.
Provisioning Object Identifier Example:
cn=John Doe,dc=acme,dc=com
Object Data
Each Provisioning Service Object (PSO) contains an identifier and data. For the SAML 2.0 Federated Provisioning Profile, the PSO Data consists of a set of SAML 2.0 Attribute elements.
Provisioning Object Data Example:
cn=John Doe,dc=acme,dc=com
jdoe@acme.com
John Doe
Schema
SPML 2.0 supports a provisioning schema (metadata) that allows for a provisioning service to publish definitions of supported object types. The schema definition language is profile-specific. As SAML 2.0 defines no such schema definition language, this proposed Federated Provisioning Profile defines one.
For the purpose of this proposal, two elements, samlprov:objectDef and samlprov:attributeDef are used to define the supported object classes that a service can provision and the attributes that are associated with the object classes. The namespace samlprov is defined in the namespace urn:oasis:names:tc:SAML:2.0:provision.
Provisioning Schema Example:
Core Capability
The SPML 2.0 protocol defines a required core capability with the following operations
Add add a new object
Modify modify an existing object
Delete delete an existing object
Lookup lookup an existing object
List targets list all targets and the provisioning schema for each target
Add Request
The SPML 2.0 Add Request provisions a new object. There are two main flavors of Add Request; the IdP may specify the new object identifier along with the object data, or it may specify the data alone and rely on the SP to define the new identifier.
Add Request Example 1 - IdP defines the new PSO ID
Request:
uid=jdoe, o=acme.com
jdoe
jdoe@acme.com
Response:
If the IdP does not supply the PSO ID, the SP must determine the PSO ID and return it in the response.
Add Request Example 2- SP defines the new PSO ID
Request:
jdoe
jdoe@acme.com
Response:
uid=jdoe, o=acme.com
Modify Request
The SPML 2.0 Modify Request modifies an existing object. The SPML 2.0 modification element defines the attribute modification type (add, replace, delete).
Modify Request Example - IdP modifies an existing PSO
Request:
uid=jdoe, o=acme.com
jane_doe@acme.com
Response:
Delete Request
The SPML 2.0 Delete Request deletes an existing object.
Delete Request Example - IdP deletes an existing PSO
Request:
uid=jdoe, o=acme.com
Response:
Lookup Request
The Lookup request returns a single PSO. The Lookup request may optionally specify that no data be returned, in which case the lookup request is an existence test.
Lookup Request Example - IdP looks up an existing PSO
Request:
uid=jdoe, o=acme.com
Response:
uid=jdoe, o=acme.com
jdoe
jdoe@acme.com
List Targets Request
The List Targets Request returns a list of provisioning targets (namespaces) that the provisioning service supports. In addition to the target names, the supported provisioning schema and capabilities for each target are returned in the response.
List Targets Request Example - IdP lists targets for a service
Request:
Response:
Search Capability
The SPML 2.0 Search Capability allows the IdP to search the SP for a list of existing PSOs. This is used to support reconciliation of accounts and other object types. The search capability supports the use of filters to scope which PSOs should be returned and also to select a subset of the data to return.
Both the search filtering and attribute selection mechanisms are profile-specific. The attribute definition elements defined in the urn:oasis:names:tc:SAML:2:0:provision schema can be used to define attribute selection criteria. A filtering mechanism will also need to be defined.
Search Request Example - IdP searches the SP for existing PSOs
Request:
ou=accounting, o=acme.com
jdoe@acme.com
Response:
uid=jdoe, o=acme.com
jdoe@acme.com
...
The Search Capability also defines an iterator for handling large data sets. If the SP determines that there are too many search results to return in one response, it may return a subset of the results along with an iterator that the IdP may use to retrieve additional search results in a subsequent call.
Response with iterator:
uid=jdoe, o=acme.com
jdoe@acme.com
...
Updates Capability
The SPML 2.0 Updates Capability allows the IdP to query the SP for changes that have occurred since a specific point in time. By asking for deltas since a specific point in time, the IdP can perform reconciliation without needing to search for all PSOs on the IdP.
Updates Request Example - IdP queries the SP for modified PSOs
Request:
Response:
uid=jdoe, o=acme.com
...
The Updates Capability also defines an iterator for handling large data sets. If the SP determines that there are too many updates results to return in one response, it may return a subset of the results along with an iterator that the IdP may use to retrieve additional updates results in a subsequent call.
Profile XSD
The SAML 2.0 Profile of SPML 2.0 requires normatively defined elements for defining the SPML 2.0 Provisioning Schema and Search Filters. The following XSD defines those elements.
) A B F R S \ d u
[ \ N
O
b
m
w
x
< N O P c h r s þ÷䒋þÒ hxu hxu h3FA h3FA hmC CJ aJ h3FA h3FA CJ aJ h3FA hxu CJ aJ h h h 5h h 5hxu B*^J ph h%> h%> h%> hxu h h2, h8 h9* hBu h(> h8 5 ( ) B F S V \ d u
N
O
w
x
gdxu gd gdxu gdxu gd%> gd%> gd8 gd8 Q
n } O P r s i x 2 gd8 gd3FA gd3FA gd gd3FA gdxu gdxu gdmC s - ` h w ( 0 M r u 5 V Z [ \ ] _ c d w ǿ h[_ h9 CJ
h CJ h h CJ
h[_ CJ
h[" CJ
h9 CJ h[_ h[_ CJ h h[_ 5h h 5h[_ h[_ hK h9 h[_ h8 hxu hxu h3FA
h3( CJ h3FA h3FA CJ 7 / 0 t u V V z > a gd%>
&