Develop a custom agent for IBM Tivoli Identity Manager with IBM Tivoli Directory Integrator

Document options Document options requiring JavaScript are not displayed Sample code Rate this page Help us improve this content

Level: Advanced

Jean-Paul Chobert (chobert@fr.ibm.com), e-business Architect, IBM

26 May 2004

This article assists developers and integrators in connecting new applications to IBM® Tivoli® Identity Manager (Identity Manager). The ability to use IBM Tivoli Directory Integrator as an Identity Manager Version 4.5 custom agent simplifies agent development and increases the ability to centrally manage identities. This article walks you though the necessary development and configuration, while demonstrating the overall account provisioning's life cycle.

Identity Management

Identity Management refers to the more efficient managing of users and their accounts in an enterprise. It fosters the usage of tools and products to centralize user definitions, access rights, and policies, as well as the ability to enforce them automatically instead of manually. It is the framework for security integration.

In this article I'll focus on the user definition and synchronization rather than on the access control or privacy control at run time provided by products such as Tivoli Access Manager and Tivoli Privacy Manager (see Resources for related links).

Autonomic computing technology

Autonomic computing technology is part of the IBM on demand environment. It complements the integration objective of the on demand environment and addresses the need to have systems manage themselves. Automation is the implementation of autonomic computing technology. It is about systems that achieve the four self attributes: self-configuring, self-healing, self-optimizing, and self-protecting.

User provisioning

Identity Management is about automating -- self-configuring an application to implement security policies and business processes related to the management of users and their accounts in the enterprise. As shown in Architecture, Identity Manager is able to interact with a remote application and its registry to define the user's rights on that application. This is the provisioning task (see Resources for a tutorial on user provisioning with Identity Manager). This activity can also be used to update or remove a given user right. Additionally, an Identity Manager administrator works on the configuration and policies that drive these actions. The administrator can define the identity policy that specifies how identities are structured, as well as a password policy and a provisioning policy. A provisioning policy defines, for users in a given role, the services they are entitled to. By enforcing security policies, Identity Manager participates in self-configuring and self-protecting applications and systems.

Tivoli Identity Manager V4.5

IBM Tivoli Identity Manager provides a secure, automated, and policy-based user management solution that helps address these key business issues across both legacy and e-business environments. Intuitive Web administrative and self-service interfaces integrate with existing business processes to help simplify and automate managing and provisioning users. It incorporates a workflow engine and leverages identity data for activities such as audit and reporting.

Agents

The communication between the Identity Manager server and the application on the remote system commonly requires an agent, although provisioning without an agent is possible in some cases. Agents have been developed by Tivoli and other vendors, and the portfolio includes major popular application ERPs, databases, and operating systems. However, there is still the need to add support to less popular applications.

Solutions involving older Identity Manager versions reused a generic CLIX agent. Starting with Identity Manager V4.5, you can benefit from the published Identity Manager APIs or use IBM Tivoli Directory Integrator V5.1.2 or 5.2 with Identity Manager V4.5.1.

Back to top

Integrate your application using Tivoli Directory Integrator

Architecture

Identity Manager and Tivoli Directory Integrator communicate using Directory Server Markup Language (DSML) V2 request and response over HTTP. DSML provides a way to represent directory-structural information as an Extensible Markup Language (XML) document. It is standardized by the Open Group OASIS (see Resources for a link on DSML V2 specification).

The DSML request uses commands such as Add, Modify, Delete, or Search to communicate. When Identity Manager sends a DSML Add request, it indicates that Tivoli Directory Integrator has to provision the destination with a new account using the related attributes of the request. When a Search request is sent, it synchronizes identities with the identity server repository; this is called reconciliation.

Tivoli Directory Integrator, however, is not the destination application itself. It acts as a server to receive the Identity Manager request and execute the tasks on its behalf. That's why the architecture involves two stages, as shown in Figure 2. The second communication is not as simple as the first one and is dependant on the technology that the target system might support.

Why is it simpler to use Tivoli Directory Integrator than to develop an agent with Identity Manager APIs?

Tivoli Directory Integrator is designed to communicate with many user registry technologies thanks to its many pre-built connectors: LDAP, MS AD, RDMS with JDBC, ODBC, Web Services, HTTP, TCP/IP, JMS, WMQ, FTP, and so on. Tivoli Directory Integrator supports the necessary connector modes to match the required operations: iteration, update, look-up, and add-only. Tivoli Directory Integrator development is limited to scriptlets stored at the needed stages of the assembly line and connector run time: before update and on no match to name a few.

Development summary

The steps to set up a custom agent are quite simple:

1. Create the assembly lines corresponding to the commands supported by the new Identity Manager service.
2. Create a DSML V2 event handler to handle the request from the Identity Manager server.
3. Assign the assembly lines to the event handler.
4. Develop each assembly line to perform the necessary action related to the application user registry technology.

Notice that the Identity Manager server configuration isn't listed here. In the next section, Example step by step, a full scenario is described.

Back to top

Example step by step: erplantservice

There is an Identity Manager service type, called IDI Data Feed, that is used to synchronize identities (users). In the example below, I could use this service profile to synchronize users to Identity Manager. However, I am focusing on accounts. The example defines a service profile, (erplantservice) and a service (PlantDbService) that are going to be used for provisioning (Add), updating (Update), or deleting (Delete) accounts. They are also going to perform reconciliation (Search) of accounts.

Plants by WebSphere® is a sample Java 2 Enterprise Edition (J2EE) application that is shipped with WebSphere Application Server Version 5. An updated version demonstrates the new functions and runs with DB2® instead of Cloudscape (see Resources for related information). You'll use this version of the application to develop and demonstrate a custom agent. The Cloudscape-supported version could be used too with some modification.

Plants by WebSphere is a sample online store where the customer information needs to be registered in a table called CUSTOMER of the PLANTSDB database, as shown in Figure 3. It holds the required information for a registered customer so that the customer is able to log in and place an order.

Instead of having the user register using the Plants Web registration form, you'll use Identity Manager to manage the user in its registry, define the Plants account, and provision it to the application's user repository. In this example, provisioning means creating one entry per user in the CUSTOMER table.

Now, look at how to set up Identity Manager and Tivoli Directory Integrator to integrate Plants by WebSphere.

Data and service model

The files within the folder /Plantservice (see the Sample source code zip file) define a data representation for this example. Three files are included:

• schema.dsml defines the directory syntax for the account and service classes.
• resource.def is the resource definition for the creation of a service profile.
• CustomLabels.properties defines labels for the forms displayed in the user interface.

The schema.dsml file contains the definitions of LDAP attributes and object classes for the account, service. They are described in Table 1.

The attributes associated with the service are described in Table 2.

Notice that in the CUSTOMER table relationship the identifier selected is going to be mapped to the e-mail address of the user "CUSTOMERID". The postal address is split into, at most, four entries "ADDR1", "ADDR2", "ADDRCITY" and "ADDRSTATE".

To load the data definitions into Identity Manager follow these steps:

1. Copy the folder /Plantservice and its contents from the example zip file to the location ${Identity Manager_HOME}\data\remote_resources.
2. Start a command line interface and change to the {$Identity Manager_HOME}\bin\win directory.
3. Execute the command config_remote_services Plantservice.
4. Restart the Identity Manager server and the Directory Server.

Add the new Identity Manager service

Now that the service profile Plantservice is available, a service instance can be created. Name it PlantsDbService. In Provisioning > Manage Services, create a new service of type "Plant Service," as shown in Figure 4

Specify the needed service attributes as shown in Figure 5. Notice that the URL port number and the naming context, dc=customer, must match to allow the conversation with Tivoli Directory Integrator.

Create the provisioning policy

Now, let's create a new provisioning policy that allows the creation of accounts with this new service. In Provisioning > Define Provisioning Policies:

1. Add a new policy called "PlantProvPolicy."
2. Fill in the General tab fields.
3. Grant the policy to a given role in the Membership tab
4. Specify Plant Service.

Assign attribute value When creating an account, the attributes can be defaulted or computed using Javascript scriptlets. This is particularly useful for automatic provisioning (entitlement type set to Automatic as opposed to Manual in Figure 6). For example, values can be retrieved from the person. Click on Get Details (to the right of the Advanced Provisioning Parameter List) and select the new attributes to work on. For example, set {subject.getProperty("cn")[0]} in cn as the default.

Notice that the provisioning policy defines a manual entitlement because the account is created from a manual interaction. But, when automatic, should a user be added in that role, the eligibility to this policy triggers the account creation without human intervention.

Back to top

Directory Integrator event handler

The event handler, as shown in Figure 7, listens to the request coming from Identity Manager and calls the corresponding assembly line: "processAdd" for Add, "processUpdate" for Modify, or "processDelete" for Delete. The HTTP port and the naming context must match the Identity Manager service.

Passing a binary attribute Enter any user-defined binary attribute (in addition the predefined LDAP binary attributes) in the extra binary attribute names field (shown in Figure 7). It is decoded before it is sent to the assembly line, or encoded before sending the response to the client. This is erpassword in the sample.

Back to top

Assembly lines for add/update/delete

In each assembly line, a JDBC connector is configured to connect to the CUSTOMER table. Note that it is in Update mode in processAdd to allow the table update in case the entry already exists. The work entries are defined in the Call/Return tab; they correspond to the DSML request attributes.

Some attributes are mapped one to one (as shown in Table 3), while others require a Javascript scriptlet.

ADDR1, ADDR2, ADDRCITY, and ADDRSTATE are mapped from postaladdress. FIRSTNAME and LASTNAME are mapped from cn. The erpassword is passed as an extra binary attribute. Erpassword is of type base64Binary, and its value can be retrieved simply by typing:

psw = work.getObject("erpassword");

However, the very simple application in this article stores the password in clear text in the database. To get it back you need to make use of a converter and use a temporary system entry:

//decoding the base 64 binary password
dec = new Packages.com.ibm.di.util.Base64EntryConverter("passwd");
e = system.newEntry();
e.setAttribute("passwd", work.getAttribute("erpassword"));
dec.base64decode(e);
//converting the binary array to a string
psw=system.arrayToString(e.getObject("passwd"));

Listing 2 shows the ADDR1 assignment. The full sample code is available for download. Note that the postaladdress work attribute is tested before the parsing.

var fulladdr=work.getString("postalAddress");
var addr1="";

if (fulladdr !=null) 
{
 var d1=0, len=0;

 // postal address is like: ADDR1 ; ADDR2 ; CITY ; STATE
 len=fulladdr.length();
 if (len>0) {                           // a postal address exist
  d1=fulladdr.indexOf(";"); 
  if (d1<=0) {                          // no ";" so everything goes into ADDR1
   addr1=fulladdr;
  }
  else {
   addr1=fulladdr.substring(0, d1);     // ADDR1
  }
 }

 var msg = "fulladdr= " + fulladdr + " len= " + len + " addr1= " + addr1;
 logmsg(msg, "Info");
 ret.value=addr1;
}

The processUpdate criteria must take into account the fact that column entries might need to be removed. For example, remove addr2 when a user changes its address. Instead of writing a blank string, the Before Modify hook checks whether there is a need to delete.

var del_addr1=false;
var del_addr2=false;
var del_city=false;
var del_state=false;

// parsed values valid only if parsing did occur
if (work.getString("postalAddress") !=null) 
{
 if((addr1=="")&&(current.getAttribute("ADDR1")!=null))     del_addr1=true;
 if((addr2=="")&&(current.getAttribute("ADDR2")!=null))     del_addr2=true;
 if((city =="")&&(current.getAttribute("ADDRCITY")!=null))  del_city=true;
 if((state=="")&&(current.getAttribute("ADDRSTATE")!=null)) del_state=true;
}
task.logmsg("About to modify " + work.getString("cn"));

The Before Applying Change hook writes an empty newly created attribute into the connector. These hooks are run only when the Compute Changes checkbox is set (see processAdd or processUpdate).

if(del_addr1) {
 task.logmsg("clearing addr1");
 ADDR1=system.newAttribute("ADDR1");
 conn.setAttribute("ADDR1",ADDR1);
}

if(del_addr2) {
 task.logmsg("clearing addr2");
 ADDR2=system.newAttribute("ADDR2");
 conn.setAttribute("ADDR2",ADDR2);
}

if(del_city) {
 task.logmsg("clearing city");
 ADDRCITY=system.newAttribute("ADDRCITY");
 conn.setAttribute("ADDRCITY",ADDRCITY);
}

if(del_state) {
 task.logmsg("clearing state");
 ADDRSTATE=system.newAttribute("ADDRSTATE");
 conn.setAttribute("ADDRSTATE",ADDRSTATE);
}

Finally, the processAdd link criteria is defined:

The processUpdate and processDelete link criteria have to be in the form of a database query. This is easily done in Javascript:

var dn=work.getString("$dn");
var coma=dn.indexOf(",");
var eq=dn.indexOf("=")+1;
var tuid=dn.substring(eq,coma);
ret.filter="CUSTOMERID LIKE '"+tuid+"'";

Back to top

Assembly line for search

This assembly line is called when a reconciliation is performed on "PlantDbService." It uses a JDBC connector in Iterator mode to scan the whole CUSTOMER table and pass back all entries found. The Call/Return parameters are a bit different this time and are assigned in the Input map:

Notice that the erplantaccount value is assigned to the objectclass that is defined in the Data Model.

Notice also that the $dn returns a eruid assignment (that is, an account). A service defined from the IDI Data Feed service profile would return a cn, a user, instead.

Back to top

Testing it all

Reconciliation

Plants by WebSphere comes with one entry in the CUSTOMER table: David Grover's account. Let's get back to this account in Identity Manager. Start the event handler in Tivoli Directory Integrator. Double-click on PlantDbService in Identity Manager Provisioning > Services. Run the reconciliation schedule.

The Directory Integrator log traces the Search request with the attributes being passed. The database connector has found one entry.

09:51:25  Connection from=127.0.0.1/127.0.0.1
09:51:25  Starting DSMLv2 event handler...
09:51:25  Initializing DSMLv2 event handler
Extracting user defined binary attributes from erpassword
09:51:25  Processing request....
09:51:25  Starting assemblyLine /AssemblyLines/processSearch
09:51:25  AssemblyLine /AssemblyLines/processSearch started
09:51:26  AssemblyLine /AssemblyLines/processSearch started
09:51:26  BEGIN prolog
09:51:26  END prolog
09:51:26  BEGIN Iteration
09:51:26  Using runtime provided entry as working entry (first pass only)
09:51:26  [FileLogger] Connector is not configured to add Entries
09:51:26  *** Begin Entry Dump
09:51:26  	Operation: generic
09:51:26  	[Attributes]
09:51:26  	   eruid (replace):	'plants@plants.com'
09:51:26  	   telephonenumber (replace):	'919-555-1234'
09:51:26  	   $dn (replace):	'eruid=plants@plants.com'
09:51:26  	   firstname (replace):	'David'
09:51:26  	   lastname (replace):	'Grover'
09:51:26  	   objectclass (replace):	'erplantaccount'
09:51:26  	   postaladdress (replace):'123 Main Street; Apt. C; 27604; Raleigh; NC'
09:51:26  	   postalcode (replace):	'27604'
09:51:26  	   erpassword (replace):	'plants'
09:51:26  	   cn (replace):	'David Grover'
09:51:26  Entry.dump.end
09:51:26  [FileLogger] Connector is not configured to add Entries
09:51:26  END Iteration
09:51:26  BEGIN Connector Statistics
09:51:26   [databaseConnector] Get:1
09:51:26   [FileLogger] Ignore:2
09:51:26  Total: Get:1, Ignore:2
09:51:26  END Connector Statistics
09:51:26  terminated successfully (0 errors)
09:51:26  AssemblyLine /AssemblyLines/processSearch terminated successfully
09:51:26  AssemblyLine completed/AssemblyLines/processSearch
09:51:31  The last message is not proper HTTP message. Closing connection...
09:51:31  Normal Termination

From Tivoli Manager, double-click PlantDbService in Identity Manager Provisioning > Services. Click Accounts. The account has been imported successfully. However, notice that there is no corresponding owner. The account is orphaned.

Look at the account details by clicking plants@plants.com. Notice the semicolons used as separators in the postal address.

Someone must adopt the orphaned account. Here, I assume that David Grover is already known in Identity Manager and might have other accounts. The reconciliation could not hook to him because the user ID (eruid) does not retrieve anything like the user name. An alias could have helped this situation. I will do the adoption manually. As in Figure 11, instead of selecting Reconciliation, select Orphan Accounts. Select the checkbox and click Adopt.

Provide the person name or run a search. Then, the userid (account) and account owner are selected. Submit this to conclude the adoption.

Create a new account

Now, the scenario is to create a new customer user with the Identity Manager user interface. For this user, create an account of type PlantDbAccount. Fill in the PlantsDbAccount form as shown in Figure 16 and submit it. The event handler receives the request and launches the processAdd assembly line. The assembly line connects to the database and creates the entry for that user.

The Directory Integrator log traces the Add request with the attributes being passed.

09:57:06  Connection from=127.0.0.1/127.0.0.1
09:57:06  Starting DSMLv2 event handler...
09:57:06  Initializing DSMLv2 event handler
Extracting user defined binary attributes from erpassword
09:57:06  Processing request....
09:57:06  Looking for binary attribute photo
09:57:06  Looking for binary attribute personalSignature
09:57:06  Looking for binary attribute audio
09:57:06  Looking for binary attribute jpegPhoto
09:57:06  Looking for binary attribute javaSerializedData
09:57:06  Looking for binary attribute thumbnailPhoto
09:57:06  Looking for binary attribute thumbnailLogo
09:57:06  Looking for binary attribute userPassword
09:57:06  Looking for binary attribute userCertificate
09:57:06  Looking for binary attribute authorityRevocationList
09:57:06  Looking for binary attribute certificateRevocationList
09:57:06  Looking for binary attribute crossCertificatePair
09:57:06  Looking for binary attribute x500UniqueIdentifier
09:57:06  Looking for binary attribute objectGUID
09:57:06  Looking for binary attribute objectSid
09:57:06  Looking for binary attribute erpassword
09:57:06  Decoding erpassword
09:57:06  Starting assemblyLine /AssemblyLines/processAdd
09:57:06  AssemblyLine /AssemblyLines/processAdd started
09:57:06  AssemblyLine /AssemblyLines/processAdd started
09:57:06  BEGIN prolog
09:57:07  END prolog
09:57:07  No iterator in AssemblyLine, will run single pass only
09:57:07  BEGIN Iteration
09:57:07  Using runtime provided entry as working entry (first pass only)
09:57:07  *** Begin Entry Dump
09:57:07  	Operation: add
09:57:07  	[Attributes]
09:57:07  	   eruid (Add):	'dupond@plants.com'
09:57:07  	   telephonenumber (Add):	'0123456789'
09:57:07  	   $dn (replace):	'eruid=dupond@plants.com,dc=customer'
09:57:07  	   firstname (Add):	'Jean'
09:57:07  	   lastname (Add):	'Dupond'
09:57:07  	   postaladdress (Add):	'8 bd St-Jacques; 3eme etage gauche; Paris'
09:57:07  	   postalcode (Add):	'75013'
09:57:07  	   erpassword[passwd] (Add):	'[B@7bb82af3'
09:57:07  	   cn (Add):	'Jean Dupond'
09:57:07  	[Properties]
09:57:07  	   event.inputstream:	'java.net.SocketInputStream@1ea9eaf3'
09:57:07  	   tcp.localPort:	'8802'
09:57:07  	   http.Content-length:	'739'
09:57:07  	   tcp.localHost:	'127.0.0.1'
09:57:07  	   http.base:	'/'
09:57:07  	   dsml.operation:	'addRequest'
09:57:07  	   http.Content-Type:	'text/xml'
09:57:07  	   http.Accept:	'text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2'
09:57:07  	   http.remote_user:	'agent'
09:57:07  	   http.remote_pass:	'agent'
09:57:07  	   event.originator:	'Thread[EventHandlers/TIM Listener[3],5,main]'
09:57:07  	   http.body:	'<?xml version="1.0" encoding="UTF-8"?>
<batchRequest requestID="2871545695096292274" processing="sequential" 
="sequential" onError="exit"
xmlns="urn:oasis:names:tc:DSML:2:0:core"><
addRequest dn="eruid=dupond@plants.com,dc=customer">
<attr 
name="postalcode"><value>75013</value></attr><attr name="telephonenumber"
><value>0123456789</value></attr><attr name="eruid"><value>dupond@plants.com
</value></attr><attr name="lastname"><value>Dupond</value></attr><
attr name="erpassword"><value>YXplcnQxMjM=</value></attr><attr name="postaladdress
"><value>8 bd St-Jacques; 3eme etage gauche; Paris</value></attr><
attr name="firstname"><value>Jean</value></attr><attr name="cn"><
value>Jean Dupond</value></attr></addRequest></batchRequest>'
09:57:07  	tcp.localIP:  '127.0.0.1'
09:57:07  	tcp.remotePort:  '1513'
09:57:07  	event.outputstream:  'java.net.SocketOutputStream@66a32af3'
09:57:07  	http.User-Agent:  'Java1.3.1'
09:57:07  	http.Authorization:  'Basic YWdlbnQ6YWdlbnQ='
09:57:07  	tcp.remoteHost:  '127.0.0.1'
09:57:07  	http.method:  'POST'
09:57:07  	dsml.base:  'eruid=dupond@plants.com,dc=customer'
09:57:07  	http.Host:	'localhost:8802'
09:57:07  	http.Connection:	'keep-alive'
09:57:07  	dsml.request:  'com.ibm.dsml2.parser.AddRequest@6c056af3'
09:57:07  	tcp.socket:  'Socket[addr=127.0.0.1/127.0.0.1,port=1513,localport=8802]'
09:57:07  	tcp.remoteIP:	'127.0.0.1'
09:57:07  Entry.dump.end
09:57:07  END Iteration
09:57:07  BEGIN Connector Statistics
09:57:07   [databaseConnector] Lookup:1, Add:1
09:57:07   [FileLogger] Not used
09:57:07  Total: Lookup:1, Add:1
09:57:07  END Connector Statistics
09:57:07  terminated successfully (0 errors)
09:57:07  AssemblyLine /AssemblyLines/processAdd terminated successfully
09:57:07  AssemblyLine completed/AssemblyLines/processAdd
09:57:12  The last message is not proper HTTP message. Closing connection...
09:57:12  Normal Termination

The CUSTOMER table is updated with the new user. Now, if you wanted, you could check that Jean Dupond is allowed to place an order in Plants.

Again, from the accounts display, Figure 11, select Accounts to see the new account for Jean Dupond as well as the reconciliated account.

Final tips

Identity Manager uses the DSML completion to either commit or roll back its task. Incomplete design of the Tivoli Directory Integrator agent might break the synchronization between Tivoli Directory Integrator and Identity Manager. Therefore, it is advised that assembly line design take into consideration any case that can occur. When writing Javascript in hooks or mapping, attributes should always be tested.

A more complex application might require that an authorization be defined, to set a group membership for example. Instead of provisioning and setting the authorization in the same assembly line, a better approach is to launch another assembly line (with main.startAL()) once provisioning is done. This solution helps contain the complexity of each assembly line.

The use of Tivoli Directory Integrator does not prevent the administrator from developing in the target application itself to relieve Tivoli Directory Integrator from in-depth application knowledge and dependency. An excellent design would be, when feasible, to expose services from the application such as create account with an attribute list. The Directory Integrator is acting as a server for requests coming from the Identity Management server toward the various applications. This follows the Service oriented Architecture paradigm, which renders integration both flexible and open.

Back to top

Download

	Information about download methods

Resources

• Visit the Tivoli security home page for information on Tivoli products including Tivoli Access Manager, Tivoli Identity Manager, Tivoli Directory Integrator and Tivoli Privacy Manager.
  
  
• User provisioning with Tivoli Identity Manager (developerWorks, September 2003) shows you how to work in conjunction with other Tivoli products to streamline the user provisioning process.
  
  
• The Open Group OASIS DSML v2.0 Specification ) describes the way to represent directory structural information as an XML document.
  
  
• The developerWorks Autonomic Computing section has articles, tutorials, and redbooks on integrating autonomic computing technology.
  
  
• "Plants by WebSphere Sample" (developerWorks, 2003) presents an updated version of the well-known sample J2EE application supporting DB2 and providing additional connectivity.
  

About the author

		Jean-Paul Chobert is an e-business Architect working in La Gaude e-business Solution Center (France) providing education, enablement, and consulting to IBM business partners. He joined IBM in 1985 and has supported business partners since 1999. Jean-Paul passed the IT Specialist certification and many product certifications in both WebSphere and Tivoli security, including Tivoli Identity Manager. His recent focus has been on security, autonomic computing technology, and orchestration and provisioning. You can reach him at chobert@fr.ibm.com.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Back to top