Sun Identity Manager 8.1 Web Services

How SPML 2.0 Concepts Are Mapped to Identity Manager

SPML 2.0 uses its own terminology to discuss the objects that are managed by a provisioning system.

Note –

See the OASIS SPML 2.0 specifications at

The following sections describe how SPML 2.0 concepts are mapped into Identity Manager:

Understanding Targets

A target is a logical end point in the server. Every target is named and declares the schema of the objects that it manages. Targets also declare which capabilities (a set of requests) are supported. See Understanding PSOs for more information.

Currently, Identity Manager supports only one target. You cannot declare multiple targets. You can name this target anything you want, but the data objects’ format must conform to the DSML profile.

A supported target is the one target defined in the spml2.xml file (Configuration:SPML2 object). For example, in ListTargetsRequest Examples, ListTargetResponse returns one target, spml2-DSML-Target.

Understanding PSOs

As mentioned in the previous section, targets manage Provisioning Service Objects (PSOs). A PSO is somewhat analogous to a view in Identity Manager, but without behavior. Consequently, you can think of a PSO as the data portion of an Identity Manager view, a User view in particular.

Note –

Identity Manager only manages Users and requires you to define a user extended attribute called spml2ObjectClass.

For Identity Manager’s purposes, a PSO is a collection of attributes that are mapped (using a form) to and from a User view. Each object specifies an objectclass attribute that is used to map the object to an objectclass definition in the schema defined for the target.

The objectclass attribute is used to find the following:

Understanding PSOIdentifiers

SPML includes an object ID that is called a PSOIdentifier (PsoID).

OASIS SPML 2.0 specifications recommend that PsoIDs be opaque to a requestor (client). Consequently, Identity Manager uses repository IDs (repoIDs) as PsoIDs when adding PSOs to the system.

A repoID is distinct and it is not meant for presentation to a user. When displaying a PSO to a user, the requestor should use the equivalent of the waveset.accountid or whatever attributes are used in the Identity template to present the object’s ID.

When identifying the PSO (as in a ModifyRequest), the requestor should use the repoID and not the waveset.accountId. Although the requestor can use the waveset.accountId as a PsoID, doing so is not recommended and it might change in a future release. Requestors should try to keep the PsoID opaque.

PSOs use an objectclass attribute to specify the object type. If this attribute is not present when a request is made, Identity Manager allows you to specify and use a “default” object class, such as SPMLUser. Internally, the objectclass value is maintained as an spml2ObjectClass attribute for users. For Identity Manager this attribute must be a user extended attribute. You might not see an spml2ObjectClass attribute for users that existed before you enabled SPML 2.0.

Understanding Open Content and OperationalAttributes

SPML makes heavy use of xsd:any elements in the .xsds file to provide what the specification refers to as Open Content. In SPML, Open Content means that most elements can contain elements of any type. Identity Manager uses this idea to provide OperationalNVPs (NameValuePairs) and OperationalAttributes that control processing. OperationalNVPs appear as elements in the XML, while OperationalAttributes appear as attributes. See the OpenSPML 2.0 Toolkit at for more information.

You can use one NVP in all requests except ListTargetsRequests, and in all responses. Identity Manager stores a sessionToken in an OperationalNVPs called session that allows the system to cache sessions on behalf of the user and improves efficiency. For more information about OperationalNVPs and OperationalAttributes, see Supported SPML 2.0 Capabilities.