|
| |
| Sun[TM] Identity Manager 8.0 Deployment Tools | |
Chapter 4
Using SPML 1.0 with Identity Manager Web ServicesService Provisioning Markup Language (SPML) 1.0 is an OASIS standard used to provide an open interface for communicating with service provisioning activities. You access Identity Manager Web services using SPML requests for HTTP.
This chapter describes SPML 1.0 support in Identity Manager and Identity Manager Service Provider and includes information about which features are supported and why, how to configure SPML 1.0 support, and how to extend support in the field.
The information is organized as follows:
Note
Identity Manager supports both SPML version 1.0 and version 2.0.
The concepts in this chapter relate specifically to SPML 1.0, but reading this chapter provides a good basis for understanding concepts described in Chapter 5, "Using SPML 2.0 with Identity Manager Web Services."
Before You BeginReview the following sections before you start working with Identity Manager Web Services:
Intended Audience
This chapter is intended for application developers and developers that are responsible for deploying Identity Manager, implementing procedural logic, and using SPML 1.0 classes to format service provisioning request messages and to parse response messages.
Important Notes
You should be aware of the following information before working with SPML 1.0:
- For optimal performance when you are working with the Identity Manager Web Service Interfaces, use the OpenSPML Toolkit that is co-packaged with Identity Manager. Using the openspml.jar file from the http://www.openspml.org/ web site might cause memory leaks.
- The Service Provider REF Kit contains an SpmlUsage.java file that demonstrates how to use the Service Provider SPML interface.
- You can access Identity Manager Service Provider (Service Provider) features through SPML 1.0. (These features are not available with SPML version 2.0.)
Related Documentation and Web Sites
In addition to the information provided in this chapter, consult the publications and web sites listed in this section for information related to using SPML.
Recommended Reading
See Chapter 5, "Using SPML 2.0 with Identity Manager Web Services," in this book for information about using SPML version 2.0.
Useful Web Sites
Visit the following web site for information about using OpenSPML and to download the OpenSPML 1.0 Toolkit.
Configuring SPMLTo expose the SPML interface, you must properly configure the Identity Manager server by installing and modifying specific repository objects and by editing the Waveset.properties file.
Instructions for configuring the SPML interface are provided in the following sections:
Installing and Modifying Repository Objects
The following table describes the repository objects you must install and modify to configure SPML for Identity Manager.
Identity Manager includes a sample set of SPML configuration objects in the sample/spml.xml file. You must manually import the sample/spml.xml file because the file is not imported by default when the repository is initialized.
The sample configuration defines a person class to track the evolving standard schema defined by the SPML working group. Do not customize this class. Keep the person class consistent with the standard schema, except in the following situation.
When configuring the Service Provider SPML interface, you must install and modify the Configuration:SPE SPML configuration object as follows:
You access the Service Provider SPML interface from the following (default) path:
/servlet/spespml
For example, if you deploy Identity Manager in the /idm context on host:port, you can access the interface at the following URL:
http://host:port/idm/servlet/spespml
Where:
- host is the machine on which you are running Identity Manager.
- port is the number of the TCP port on which the server is listening.
Note
See the SPML 1.0 Specification at http://www.openspml.org/ for the most current information about the standard SPML schema.
Editing the Waveset.properties File
The following table describes three optional entries in the Waveset.properties file that you can use to control how SPML requests are authorized.
Editing soap.epassword and soap.password Properties
A user specified in soap.username is known as the proxy user.
You can define a proxy user in soap.username and specify only one of the following password properties:
Establishing a proxy user is convenient for clients because authentication is not required by the web service. This configuration is common for portal environments where the Identity Manager server is only accessed by other applications that handle user authentication.
The SPML standard does not specify how to perform authentication and authorization. Several related web standards are available for authentication, but these standards are not yet in common use. At this time, the most common approach for authentication is to use SSL between applications and the server. Identity Manager does not dictate how to configure SSL.
If you cannot use a proxy user or SSL, Identity Manager supports a vendor-specific extension to SPML that allows the client to log in and maintain a session token, which can be used to authenticate subsequent requests. You can use the LighthouseClient class (an extension of the SpmlClient class that includes support for specifying credentials) to perform a log in request and pass a session token in all SPML requests.
Creating an Encrypted Password
Use one of the following methods to create an encrypted password:
Editing Configuration Objects
Applications require a mechanism to send SPML messages and receive SPML responses.
To configure SPML for Identity Manager, you must configure the following configuration objects:
Configuration: SPML Object
The SPML object contains definitions for the SPML schemas 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:
- Schemas: A list of strings, where each string contains the escaped XML for one SPML <schema> element. Because the SPML elements are not defined in waveset.dtd, you cannot directly include them in an Identity Manager XML document. Instead, you must include them as escaped text.
- Classes: A list of objects containing information about the supported SPML classes and how those classes are mapped onto views. Define one object on this list for each class defined by the SPML schemas on the schemas list.
Initially, the distinction between the two lists might be confusing. The information about the schemas list defines what Identity Manager returns in response to an SPML SchemaRequest message. This information can be used by the client to understand 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 have not defined 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, so you can 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.
Two classes are defined in this example:
The following attributes are supported in a class definition:
- name: Identifies the name of the class. The name value can correspond to an <ObjectClassDefinition> element in an SPML schema, although this value is not required. You can use this name as the value for the objectclass attribute in an Add request or Search request.
- type: Defines the Identity Manager view type used to manage instances of this class. Generally, this attribute is User, but can be any repository type that is accessible through a view. For information about views, see Sun Java™ System Identity Manager Workflows, Forms, and Views.
- form: Identifies the name of a configuration object containing a form. This attribute contains the rules for transforming between the external attributes defined by the class and the internal view attributes.
- default: Specify true to indicate that this attribute is the default class for this type only. For more than one SPML class implemented on the same type, you must designate one class as the default.
- identifier: Each class typically defines one attribute that is considered to be the identity of the object. Where possible, the value of this attribute is used as the name of the corresponding repository object that you create to represent the instance. The identifier attribute in the class definition specifies which attribute represents the identity.
- filter: When evaluating an SPML search request for a class, you typically include all repository objects associated with that class in that search. This approach is fine for User objects, but some classes might be implemented by using generic types such as TaskDefinition or Configuration, not all of which are considered instances of the SPML class.
To prevent unwanted objects from being included in the search, you can specify the filter attribute. The value is expected to be an <AttributeCondition> element or a <List> of <AttributeCondition> elements. Because custom classes are typically created for the User type, using a filter is uncommon. The default configuration uses them to expose a subset of the TaskInstance objects that are known to have been created to handle asynchronous SPML requests.
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 < and > character entities.
The default configuration includes two schemas:
Configuration: SPMLPerson Object
Each class defined in Configuration:SPML typically has an associated form object that contains 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.
Code Example 4-2 Standard Person Class References Form
<Configuration name='SPMLPerson'>
<Extension>
<Form><Field name='cn'>
<Derivation><ref>global.fullname</ref></Derivation>
</Field>
<Field name='global.fullname'>
<Expansion><ref>cn</ref></Expansion>
</Field><Field name='email'>
<Derivation><ref>global.email</ref></Derivation>
</Field>
<Field name='global.email'>
<Expansion><ref>email</ref></Expansion>
</Field><Field name='description'>
<Derivation>
<ref>accounts[Lighthouse].description</ref>
</Derivation>
</Field>
<Field name='accounts[Lighthouse].description'>
<Expansion><ref>description</ref></Expansion>
</Field><Field name='password'>
<Derivation><ref>password.password</ref></Derivation>
</Field>
<Field name='password.password'>
<Expansion><ref>password</ref></Expansion>
</Field><Field name='sn'>
<Derivation><ref>global.lastname</ref></Derivation>
</Field>
<Field name='global.lastname'>
<Expansion><ref>sn</ref></Expansion>
</Field><Field name='gn'>
<Derivation><ref>global.firstname</ref></Derivation>
</Field>
<Field name='global.firstname'>
<Expansion><ref>gn</ref></Expansion>
</Field><Field name='telephone'>
<Derivation>
<ref>accounts[Lighthouse].telephone</ref>
</Derivation>
</Field>
<Field name='accounts[Lighthouse].telephone'>
<Expansion><ref>telephone</ref></Expansion>
</Field></Form>
</Extension>
</Configuration>
For each attribute in a class definition there is a pair of field definitions. One field uses a <Derivation> expression to transform the internal view attribute name to the external name. One field uses an <Expansion> expression to transform the external name to the internal name.
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 the results of the <Expansion> expressions 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 number 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, the attribute must be declared as extended so that the value is accessible when the repository query indexes are built.
If you want 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 the IDMAttributeConfigurations. Only firstname, lastname, and telephone are queryable and summary attributes.
Code Example 4-3 telephone and description Declared as Extended Attributes
<Configuration name="IDM Schema Configuration"
id='#ID#Configuration:IDM_Schema_Configuration'
authType='IDMSchemaConfig'>
<IDMSchemaConfiguration>
<IDMAttributeConfigurations>
<!-- this is the standard set -->
<IDMAttributeConfiguration name='firstname'
syntax='STRING'/>
<IDMAttributeConfiguration name='lastname'
syntax='STRING'/>
<IDMAttributeConfiguration name='fullname'
syntax='STRING'/>
<!-- these are the SPML extensions -->
<IDMAttributeConfiguration name='description'
syntax='STRING'/>
<IDMAttributeConfiguration name='telephone'
syntax='STRING'/>
</IDMAttributeConfigurations>
<IDMObjectClassConfigurations>
<IDMObjectClassConfiguration name='User'
extends='Principal'
description='User description'>
<IDMObjectClassAttributeConfiguration name='firstname'
queryable='true'
summary='true'/>
<IDMObjectClassAttributeConfiguration name='lastname'
queryable='true'
summary='true'/>
<IDMObjectClassAttributeConfiguration name='fullname'/>
<IDMObjectClassAttributeConfiguration name='description'/>
<IDMObjectClassAttributeConfiguration name='telephone'
queryable='true'
summary='true'/>
</IDMObjectClassConfiguration>
</IDMObjectClassConfigurations>
</IDMSchemaConfiguration>
</Configuration>
You can customize the list of attributes according to the needs of your site.
The names you choose for the extended attributes depend on the mappings performed in the class form. Because the default SPMLPerson form maps sn into lastname, the extended attribute must be declared as lastname. Because the form does not transform the name of telephone or description, 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 to be queryable (that is, usable in an SPML filter) and which are to be summary attributes (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. This task is used 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.
<TaskDefinition name='SPMLRequest'
executor='com.waveset.rpc.SpmlExecutor'
execMode='asyncImmediate'
resultLimit='86400'>
</TaskDefinition>
You must not change the name of the definition, the name of the executor, or the execution mode. However, you might want to 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 SPMLRequests 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.
Deployment Descriptor
You must edit the Identity Manager deployment descriptor, typically found in the file WEB-INF/web.xml, 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.
Code Example 4-4 Servlet Declaration
<servlet>
<servlet-name>rpcrouter2</servlet-name>
<display-name>OpenSPML SOAP Router</display-name>
<description>no description</description>
<servlet-class>
org.openspml.server.SOAPRouter
</servlet-class>
<init-param>
<param-name>handlers</param-name>
<param-value>com.waveset.rpc.SimpleRpcHandler</param-value>
</init-param>
<init-param>
<param-name>spmlHandler</param-name>
<param-value>com.waveset.rpc.SpmlHandler</param-value>
</init-param>
<init-param>
<param-name>rpcHandler</param-name>
<param-value>com.waveset.rpc.RemoteSessionHandler</param-value>
</init-param>
</servlet>
This declaration allows you to access the addRequest, modifyRequest, and searchRequest web services through the URL:
http://<host>:<port>/idm/servlet/rpcrouter2
Where
Although you can, you are not required to define a <servlet-mapping>. Do not modify the contents of this servlet declaration.
Starting the SPML BrowserYou can use the OpenSPML Browser application to test the Identity Manager SPML configuration.
To start the browser,
Connecting to the Identity Manager ServerTo connect to the Identity Manager server,
Testing and Troubleshooting Your SPML ConfigurationTo test your SPML configuration:
If you cannot establish a successful connection
- Verify that you typed the URL correctly.
- If the error you receive contains phrases such as “no response” or “connection refused,” then the problem is most likely the host or port used in the connection URL.
- If the error suggests that a connection was made, but the web application or servlet could not be located, the problem is most likely in the
WEB-INF/web.xml file. See “Deployment Descriptor” on page 43 for more information.
Developing SPML ApplicationsAfter configuring the server, your SPML application requires a mechanism for sending SPML messages and receiving SPML responses. For Java applications, use the OpenSPML Toolkit to configure this mechanism.
Note
For optimal performance when you are working with the Identity Manager Web Service Interfaces, use the OpenSPML Toolkit that is co-packaged with Identity Manager.
Using the openspml.jar file from the http://www.openspml.org/ web site might cause memory leaks.
The toolkit can provide the following components:
The following table describes the most important classes provided by the OpenSPML Toolkit. Each request type has a corresponding class. Consult the JavaDocs distributed with the toolkit for complete information.
Table 4-3 Classes Provided by OpenSPML Toolkit
Class
Description
AddRequest
Constructs a message to request creation of a new object.
You define the object type by passing an objectclass attribute. Other passed attributes must adhere to the schema associated with the object class. SPML does not yet define standard schemas, but you can configure Identity Manager to support almost all schemas.BatchRequest
Constructs a message that can contain more than one SPML request.
CancelRequest
Constructs a message to cancel a request that was formerly executed asynchronously.
DeleteRequest
Constructs a message to request the deletion of an object.
ModifyRequest
Constructs a message to request modification of an object. Include only those attributes that you want to modify in the request. Attributes not included in the request retain their current value.
SchemaRequest
Constructs a message to request information about SPML object classes supported by the server.
SearchRequest
Constructs a message to request object attributes that match certain criteria.
SpmlClient
Presents a simple interface for sending and receiving SPML messages.
SpmlResponse
Includes the base class for objects representing response messages sent back from the server. Each request class has a corresponding response class. For example, AddResponse and ModifyResponse.
StatusRequest
Constructs a message to request the status of a request that was formerly executed asynchronously.
The Service Provider REF Kit contains an SpmlUsage.java file that demonstrates how to use the Service Provider SPML interface. This REF Kit also contains an ant script that compiles the SpmlUsage class.
Usage:
java [ -Dtrace=true ] com.sun.idm.idmx.example.SpmlUsage [ URL ]
Where URL points to the Service Provider SPML interface and defaults to
http://host:port/idm/spespml
Where
You can enable trace for Service Provider to print Service Provider SPML messages to standard output.
ExtendedRequest Examples
The following table describes the different ExtendedRequest classes you can use to send messages to and receive messages from the client.
Table 4-4 ExtendedRequest Classes for Sending and Receiving Messages
ExtendedRequest
Description
changeUserPassword
Constructs a message to request a user password change.
deleteUser
Constructs a message to request the deletion of a user.
disableUser
Constructs a message to request the disabling of a user.
enableUser
Constructs a message to request the enabling of a user.
launchProcess
Constructs a message to request the launch of a process.
listResourceobjects
Constructs a message to request the name of a resource object in the Identity Manager repository, and the type of object supported by that resource. The request returns a list of names.
resetUserPassword
Constructs a message to request the reset of a user password.
runForm
Allows you to create custom SPML requests that return information obtained by calling the Identity Manager Session API.
The server code converts the ExtendedRequests into view operations.
Examples using the typical formats for these classes are presented in the following sections:
ExtendedRequest Example
The following example shows the typical format for an ExtendedRequest.
Code Example 4-5 ExtendedRequest Format
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("changeUserPassword");
req.setAttribute("accountId", "exampleuser");
req.setAttribute("password", "xyzzy");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
Most SPML ExtendedRequests accept the following arguments:
If you do not pass an accounts attribute, the operation updates all resource accounts linked to the user, including the Identity Manager user account. If you do pass accounts, the specified SPML operation only updates the specified resources. You must include Lighthouse in a non-null accounts list if you want to update the Identity Manager user in addition to specific resource accounts.
deleteUser Example
The following example shows the typical format for a deleteUser request
(View > Deprovision view).
Code Example 4-6 deleteUser Request
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("deleteUser");
req.setAttribute("accountId","exampleuser");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
disableUser Example
The following example shows the typical format for a disableUser request
(View > Disable view).
Code Example 4-7 disableUser Request
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("disableUser");
req.setAttribute("accountId","exampleuser");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
enableUser Example
The following example shows the typical format for an enableUser request
(View > Enable view).
Code Example 4-8 enableUser Request
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("enableUser");
req.setAttribute("accountId","exampleuser");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
launchProcess Example
The following example shows the typical format for a launchProcess request.
(View > Process view).
Code Example 4-9 launchProcess Request
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("launchProcess");
req.setAttribute("process", "my custom process");
req.setAttribute("taskName", "my task instance");
ExtendedResponse res = (ExtendedResponse) client.send(req);
Where:
The remaining attributes are arbitrary and they are passed into the task.
listResourceObjects Example
The following example shows the typical format for a listResourceObjects request.
Code Example 4-10 listResourceObjects Request
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("listResourceObjects");
req.setAttribute("resource", "LDAP");
req.setAttribute("type", "group");
ExtendedResponse res = (ExtendedResponse) client.send(req);
Where:
resetUserPassword Example
The following example shows the typical format for a resetUserPassword request (View > Reset User Password view).
Code Example 4-11 resetUserPassword Request
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("resetUserPassword");
req.setAttribute("accountId","exampleuser");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
runForm Example
The following example shows the typical format for a runForm request.
Code Example 4-12 runForm Request
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("runForm");
req.setAttribute("form", "SPML Get Object Names");
ExtendedResponse res = (ExtendedResponse) client.send(req);
Where form is the name of a Configuration object containing a form.
Example Form
The following example shows a form that runs queries and returns a list of the Role, Resource, and Organization names accessible to the current user.
Code Example 4-13 Query Form
<Configuration name='SPML Get Object Names'>
<Extension>
<Form>
<Field name='roles'>
<Derivation>
<invoke class='com.waveset.ui.FormUtil'>
<ref>display.session</ref>
<s>Role</s>
</invoke>
</Derivation>
</Field>
<Field name='resources'>
<Derivation>
<invoke class='com.waveset.ui.FormUtil'>
<ref>display.session</ref>
<s>Resource</s>
</invoke>
</Derivation>
</Field>
<Field name='organizations'>
<Derivation>
<invoke class='com.waveset.ui.FormUtil'>
<ref>display.session</ref>
<s>ObjectGroup</s>
</invoke>
</Derivation>
</Field>
</Form>
</Extension>
</Configuration>
You use the runForm request to create custom SPML requests that return information obtained by calling the Identity Manager Session API. For example, when configuring a user interface for editing users, you might want to provide a selector that displays the names of the organizations, roles, resources, and policies that can be assigned to a user.
You can configure the SPML interface to expose these objects as SPML object classes and use a searchRequest to query for their names. However, this configuration requires four searchRequests to gather the information. To reduce the number of SPML requests, encode the queries in a form by using a single runForm request to perform the queries, and returning the combined results.
Using Trace with SPML
SPML includes 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 the “Tracing and Troubleshooting Identity Manager” chapter in the Identity Manager Tuning, Troubleshooting, and Error Messages book.
Example Methods for Implementing SPMLThis section presents examples that show several common methods for implementing SPML:
Add Request
An example Add Request is shown in Code Example 4-14:
Code Example 4-14 Add Request
SpmlClient client = new SpmlClient();
client.setURL("http://example.com:8080/idm/spml");AddRequest req = new AddRequest();
req.setObjectClass("person");
req.setIdentifier("maurelius");
req.setAttribute("gn", "Marcus");
req.setAttribute("sn", "Aurelius");
req.setAttribute("email", "maurelius@example.com");SpmlResponse res = client.request(req);
if (res.getResult() .equals(SpmlResponse.RESULT_SUCCESS))
System.out.println("Person was successfully created");
Modify Request
This section contains two, example Authenticated SPML Modify Requests.
Code Example 4-15 Authenticated SPML Request
SpmlClient client = new SpmlClient();
client.setURL("http://example.com:8080/idm/spml");ModifyRequest req = new ModifyRequest();
req.setIdentifier("maurelius");
req.setModification("email", "marcus.aurelius@example.com");SpmlResponse res = client.request(req);
if (res.getResult() .equals(SpmlResponse.RESULT_SUCCESS))
System.out.println("Person was successfully modified");
Code Example 4-16 Authenticated SPML Request with LighthouseClient
LighthouseClient client = new LighthouseClient();
client.setURL("http://example.com:8080/idm/spml");
client.setUser("maurelius");
client.setPassword("xyzzy");ModifyRequest req = new ModifyRequest();
req.setIdentifier("maurelius");
req.setModification("email", "marcus.aurelius@example.com");SpmlResponse res = client.request(req);
if (res.getResult() .equals(SpmlResponse.RESULT_SUCCESS))
System.out.println("Person was successfully modified");
The only difference between these examples is that the Code Example 4-16 uses the LighthouseClient class and two additional method calls to client.setUser and client.setPassword. For example, you could use this example to avoid setting a proxy user in Waveset.properties, which results in the audit log reflecting the specified user instead of the proxy user.
This example is authenticated by client.setUser and client.setPassword when the request is sent.
Search Request
An example Search Request is shown in Code Example 4-17:
Code Example 4-17 Search Request
SpmlClient client = new SpmlClient();
client.setURL("http://example.com:8080/idm/spml");
SearchRequst req = new SearchRequest();
// specify the attributes to return
req.addAttribute("sn");
req.addAttribute("email");
// specify the filter
FilterTerm ft = new FilterTerm();
ft.setOperation(FilterTerm.OP_EQUAL);
ft.setName("gn");
ft.setValue("Jeff");
req.addFilter(ft);
SearchResponse res = (SearchResponse)client.request(req);
// display the results
List results = res.getResults();
if (results != null) {for (int i = 0 ; i < results.size() ; i++) {
SearchResult sr = (SearchResult)results.get(i);
System.out.println("Identifier=" +
sr.getIdentifierString() +
" sn=" +
sr.getAttribute("sn") +
" email=" +
sr.getAttribute("email"));
}
}
