Sun Identity Manager 8.1 Web Services

Editing Configuration Objects

Applications require a mechanism to send SPML messages and to receive SPML responses.

To configure SPML for Identity Manager, you must edit the following configuration objects:

Note –

The Service Provider SPML interface has only one configuration object, Configuration:SPE SPML, which is similar to the Configuration:SPML object in structure.

Configuration: SPML Object

The Configuration: SPML object contains definitions for the SPML schemas that you want to expose, and information about how those SPML schemas are mapped into Identity Manager views. This information is represented by using a GenericObject that is stored as an extension of the configuration object.

The following attributes are defined in GenericObject: schemas and classes:

Initially, the distinction between the two lists might be confusing. The information in the schemas list defines what Identity Manager returns in response to an SPML SchemaRequest message. The client uses this information to decide which attributes can be included in other messages such as AddRequest. Identity Manager does not care about the contents of the schemas list. This list is simply returned verbatim to the client.

You are not required to define SPML schemas. Identity Manager works without schemas. If you do not define an SPML schema, Identity Manager returns an empty response after receiving a schema request message. Without a schema, clients must rely on pre-existing knowledge about the supported classes and attributes.

Best Practice:

Writing SPML schemas is considered a best practice, because it enables you to use general purpose tools (such as the OpenSPML Browser) to build requests.

Default SPML Configuration

The following example shows the default SPML configuration. The text of the SPML schema definitions have been omitted for brevity.

Example 1–1 Default SPML Configuration

<Configuration name='SPML' authType='SPML'>
  <Attribute name='classes'>
      <Object name='person'>
        <Attribute name='type' value='User'/>
        <Attribute name='form' value='SPMLPerson'/>
        <Attribute name='default' value='true'/>
        <Attribute name='identifier' value='uid'/>
      <!-- Class 'user' defines no form so we'll default to a builtin 
simplified schema. I don't really like this but SimpleRpc currently depends on it.
      <Object name='user'>
        <Attribute name='type' value='User'/>
        <Attribute name='identifier' value='waveset.accountId'/>
      <!-- Class 'userview' defines the form "view" which causes the view 
to pass through unmodified-->      <Object name='userview'>
        <Attribute name='type' value='User'/>
        <Attribute name='form' value='view'/>
        <Attribute name='identifier' value='waveset.accountId'/>
        <Attribute name='multiValuedAttributes'>
      <Object name='role'>
        <Attribute name='type' value='Role'/>
        <Attribute name='form' value='SPMLRole'/>
        <Attribute name='default' value='true'/>
        <Attribute name='identifier' value='name'/> <!--  attribute ...for now? -->

Two classes are defined in this example:

The following attributes are supported in a class definition:

Default Schemas

The schemas attribute contains a list of strings that contain the escaped XML for an SPML <schema> element. If you examine the spml.xml file, note that the schema elements are surrounded by a CDATA-marked section. Using CDATA-marked sections is convenient for escaping long strings of XML. When Identity Manager normalizes the spml.xml file, the CDATA-marked sections are converted into strings containing &lt; and &gt; character entities.

The default SPML configuration includes two schemas:

Configuration: SPMLPerson Object

Each class defined in the Configuration:SPML object typically has an associated form object containing the rules for transforming between the external attribute model defined by the class and the internal model defined by the associated view.

The following example shows how the standard person class references a form.

Example 1–2 Standard Person Class Referencing a Form

<Configuration name='SPMLPerson'>
         <Field name='cn'>
         <Field name='global.fullname'>
         <Field name='email'>
         <Field name=''>
         <Field name='description'>
         <Field name='accounts[Lighthouse].description'>
         <Field name='password'>
         <Field name='password.password'>
         <Field name='sn'>
         <Field name='global.lastname'>
         <Field name='gn'>
         <Field name='global.firstname'>
         <Field name='telephone'>
         <Field name='accounts[Lighthouse].telephone'>

SPML class forms

Each attribute in a class definition contains two field definitions:

The form is processed in such a way that when attributes are returned to the client, only the result of the <Derivation> expressions are included. When attributes are being sent from the client to the server, only <Expansion> expression results are assimilated back into the view. The effect is similar to the schema map of a Resource definition.

Configuration: IDM Schema Configuration Object

If you want to use attributes in an SPML search filter, you must define those attributes as extended attributes for Identity Manager users. Identity Manager stores extended attribute values in the repository, even when that value is also stored as a resource account attribute.

Try to minimize the use of extended attributes. Too many extended attributes can increase the repository size and might cause consistency problems between attributes stored in Identity Manager and the real value of the attribute stored on a resource. To use an attribute in an Identity Manager query, you must declare the attribute as an extended attribute to ensure that the value is accessible when the repository query indexes are built.

To include attributes in a user’s set of summary attributes, you must define those attributes as extended attributes. You can use summary attributes to optimize searches by avoiding deserialization of the object XML, and instead return only a few of the most important user attributes. In the Identity Manager SPML implementation, summary attributes are returned when you do not explicitly provide a list of return attributes in the search request.

In the following example, firstname, lastname, fullname, description, and telephone are extended attributes that are present on the User IDMObjectClassConfiguration after being defined in IDMAttributeConfigurations. Only firstname, lastname, and telephone are queryable and summary attributes.

Example 1–3 telephone and description Declared as Extended Attributes

<Configuration name="IDM Schema Configuration"
               <!-- this is the standard set -->
               <IDMAttributeConfiguration name=’firstname’
               <IDMAttributeConfiguration name=’lastname’
               <IDMAttributeConfiguration name=’fullname’
               <!-- these are the SPML extensions -->
               <IDMAttributeConfiguration name=’description’
               <IDMAttributeConfiguration name=’telephone’
               <IDMObjectClassConfiguration name=’User’
                                            description=’User description’>
                   <IDMObjectClassAttributeConfiguration name=’firstname’
                   <IDMObjectClassAttributeConfiguration name=’lastname’
                   <IDMObjectClassAttributeConfiguration name=’fullname’/>
                   <IDMObjectClassAttributeConfiguration name=’description’/>
                   <IDMObjectClassAttributeConfiguration name=’telephone’

You can customize the list of attributes according to the needs of your site.

The names you choose for extended attributes depend on the mappings performed in the class form. Because the default SPMLPerson form maps sn into lastname, you must declare the extended attribute as lastname. The form does not transform the name of telephone or description, so the extended attribute name comes directly from the SPML schema.

Beyond declaring extended attributes, you must also modify the same Configuration: object to declare which of the attributes are queryable, or usable in an SPML filter, and which attributes are summary attributes to be returned by an optimized search result.

TaskDefinition: SPMLRequest Object

The spml.xml file also includes a brief definition for a new system task named SpmlRequest. You can use this task to implement asynchronous SPML requests. When the server receives an asynchronous request, it launches a new instance of this task and passes the SPML message as an input variable for the task. The server then returns the task instance repository ID in the SPML response for later status requests. For example:

<TaskDefinition name=’SPMLRequest’

Do not change the definition name, the executor name, or the execution mode. You can change the resultLimit value. When asynchronous requests have completed, the system typically retains the result value for a specified time so the client can issue an SPML status request to obtain the results. How long to retain these results is site-specific.

Use a positive resultLimit value to specify how long (in seconds) the system can retain results after completing a task. The default value for SPMLRequest is typically 3600 seconds or approximately one hour. Other tasks default to 0 seconds unless you change the task name to a different value.

If negative, the request instance is never removed automatically.

Tip –

To avoid cluttering the repository, set the resultLimit value to the shortest possible time.

Note –

The Service Provider SPML interface does not support asynchronous requests.

Deployment Descriptor

You must edit the Identity Manager deployment descriptor, typically found in the WEB-INF/web.xml file, to contain a declaration for the servlet that receives SPML requests.

If you are having difficulty contacting the SPML web service, look in the web.xml file for a servlet declaration. The following example shows a servlet declaration.

Example 1–4 Servlet Declaration

   <display-name>OpenSPML SOAP Router</display-name>
   <description>no description</description>

This declaration allows you to access addRequest, modifyRequest, and searchRequest web services through the URL:



Although you can, you are not required to define a servlet-mapping. Do not modify the contents of this servlet declaration.