This section describes how to configure Identity Manager to use SPML 2.0. The configuration involves the following:
When configuring an Identity Manager server to use SPML 2.0, the first step is to decide which attributes you want to manage through your target.
You can have more than one attribute in the target.
Decide which attribute sets, or object classes, the interface clients can employ to manage users in the Identity Manager instance using this interface. This set of attributes is a PSO. You must know how to map these attributes to and from a User view using a form.
This section describes how to configure a system using PSOs that contain the following attributes for a DSML object class called spml2Person:
You must map these attributes to the User view.
This section also provides short examples that demonstrate how to manage PSOs using SPML 2.0 support in Identity Manager.
Identity Manager provides a sample set of SPML configuration objects in the sample/spml2.xml file. The sample/spml2.xml file is not imported when the repository is initialized, so you must manually import the file. See the contents of this file for detailed information.
The spml2ObjectClass attribute is not present in the User schema by default. If this attribute is not already enabled, you must manually add the spml2ObjectClass attribute to your schema before Identity Manager can function as an SPML 2.0 server.
The spml2ObjectClass attribute has been defined in the schema.xml file supplied with Identity Manager, but the section where you add this attribute to the configuration is commented out. Assuming that your production schema is in a file derived from that original, you can uncomment that section, import or re-import the schema file, and restart Identity Manager to enable use of the SPML 2.0 feature.
After deciding on the format of a PSO, enable the service as described in the following sections. These sections also contain information about configuring the web.xml file and what features have been added for SPML 2.0.
The sample/spml2.xml file contains an out-of-the-box configuration for SPML 2.0 support. You can import this file, or one derived from this file, to define the objects that Identity Manager needs to support SPML 2.0.
You can use the SPML2 configuration object type to change how SPML 2.0 support behaves or to extend the system.
See Extending the System for more information about extensions.
If you are using a servlet container such as Tomcat, you can use the web.xml file to set up the openspmlRouter servlet, which handles SPML 2.0 requests.
The web.xml file ships with a default installation, so no action is required.
The web.xml file contains an optional init-param parameter that you can use to open a monitor window (in Swing) that displays the flow of SPML 2.0 messages. You can use this window to monitor the flow of SPML 2.0 messages, which can be useful for debugging purposes.
The following example shows how to add the lisinit-param parameter.
<init-param> <param-name>monitor</param-name> <param-value>org.openspml.v2.util.SwingRPCRouterMonitor</param-value> </init-param>
The next example contains a commented section and includes information about other init-param parameters.
<servlet> <servlet-name>openspmlRouter</servlet-name> <display-name>OpenSPML SOAP Router</display-name> <description>A router of RPC traffic - nominally SPML 2.0 over SOAP</description> <servlet-class> org.openspml.v2.transport.RPCRouterServlet </servlet-class> <!-- The Router uses dispatchers to process SOAP messages. This is one that is in the toolkit that knows about SOAP. It has its own parameters, via naming convention. See below. --> <init-param> <param-name>dispatchers</param-name> <param-value>org.openspml.v2.transport.SPMLViaSoapDispatcher</param-value> </init-param> <!-- Turn on trace to have the servlet write informational messages to the log. --> <init-param> <param-name>trace</param-name> <param-value>false</param-value> </init-param> <!-- The SpmlViaSOAPDispatcher uses marshallers; there can be a chain, to move XML to SPML objects and back. --> <init-param> <param-name>SpmlViaSoap.spmlMarshallers</param-name> <param-value>com.sun.idm.rpc.spml2.UberMarshaller</param-value> </init-param> <!-- Our marshaller (UberMarshaller) has its own trace setting; which doesn't really do anything in this release --> <init-param> <param-name>SpmlViaSoap.spmlMarshallers.UberMarshaller.trace</param-name> <param-value>true</param-value> </init-param> <!-- Finally, the dispatcher has a list of executors that actually implement the functionality. So, it sees a request, takes the SOAP envelope off, takes the body from XML to OpenSPML Request classes, and then asks the list of executors if they can process it. UberExecutor will redispatch the request to other executors. Those are specified in spml2.xml (Configuration:SPML2). --> <init-param> <param-name>SpmlViaSoap.spmlExecutors</param-name> <param-value>com.sun.idm.rpc.spml2.UberExecutor</param-value> </init-param> </servlet>
SPML provides options for turning on trace output so you can log Identity Manager’s SPML traffic and diagnose problems.
For more information about tracing SPML, see Chapter 5, Tracing and Troubleshooting, in Sun Identity Manager 8.1 System Administrator’s Guide.