IdM Quick Reference

Workflow:

Def:

A workflow is a logical, repeatable process during which documents, information, or tasks are passed from one participant to another for action, according to a set of procedural rules.

Workflow features:

i) Most IDM tasks you perform are defined as a set of workflow processes.

ii) Workflows can be customized using IDM IDE.

iii) In the IDM repository the WF exists as a configuration object of type WFProcess.

iv) WF processes can be accessed by looking at the list of TaskDefinition from the Debug page of the IDM administrator interface.

Workflow engine:

Once a workflow task is launched, the workflow engine creates a TaskInstance in the repository.

Functions provided by the work engine are,

i) Interpreting the process definition

ii) Creating process instances & managing their execution

iii) Navigating between activities & creating work items for their processing

Workflow ENGINE has several built-in variables which provide the following data:

i) Related to the state of the workflow execution.

ii) Outcome from the workflow services.

Workflow Process:

Defines workflow activities (Activity), relationships (Transition) between them & criterion (Action) to start, advance & complete a process.

Workflow Sub-Process:

Defines a set of activities, actions, and transitions that can be called from other activities in the process.

Work Item [Manual Action]:

When the workflow engine processes a manual action, a WorkItem object is created in the repository.

Unless the WorkItem is marked as Complete the WF doesn’t proceed.

The WorkItem table is under Approvals tab, as the WorkItems are usually used to represent approvals.

iGATE Sensitive

IdM Quick Reference

Work Item Types:

Manual actions have the ability to assign a type to the work item that is generated when the manual action is executed by the workflow engine. You can assign the work item type in a customization to filter the set of work items to be displayed or operated upon.

<ManualAction itemType='approval'>

The following work item types are recognized by the system.

Table 1-2 Work Item Types

Work Item Type Description

approval Indicates that the work item represents an approval.

wizard Indicates that the work item represents an arbitrary interaction with the user.

suspend Indicates that the work item is temporary. Use this type to force a workflow into background execution.

In addition, you can assign customized work item types. For example, you might set the work item type to resource to represent a resource approval and role to represent a role approval.

Manual WorkItem:

A manual action is part of the workflow process definition that defines a manual interaction. When the workflow engine processes a manual action, a WorkItem object created in the repository. The work item must be marked "complete" before the workflow can proceed. Since most manual actions are used to solicit approvals, the work item table is under the Approvals tab.

Any manual action that belongs to a workflow is represented by a WorkItem object in the repository.

TaskInstance:

TaskInstance is an object in the repository that holds the runtime state of an executing workflow process. It stores context variables and immediate transition information for the TaskDefinition from which it was spawned.

Task Instance is the run-time representation of the Task Definition (Workflow) & store context variables & immediate transition information.

Task Instance deletion depends on the value of the “resultLimit” parameter. 0 indicates the task will be deleted immediately after completion & a positive value indicates the # of minutes the task is kept.

The launched instance of a Task Definition is represented as a Task Instance object, which you can also view from the Debug page.

iGATE Sensitive

IdM Quick Reference

Invoke:

The invoke function is frequently used to call the WorkflowContext class along with its use to call the java methods.

Complex workflow actions can be implemented in Java.

<Activity name='Log Status'>

<Action>

<expression>

<invoke name='logStatus'

class='custom.OracleStatusLog'>

<ref>accountId</ref>

<ref>email</ref>

<ref>status</ref>

</invoke>

</expression>

</Action>

<Transition to='Next'/>

</Activity>

Standard Workflow Configuration Parameters:

taskType

executor

Suspendedable

syncControlAllowed

execMode

executionLimit

resultLimit

resultOption

visibility

iGATE Sensitive

IdM Quick Reference

syncExec

progressInterval

Workflow Engine Built-In Variables:

WF_ACTION_ERROR

WF_ACTION_RESULT

WF_ACTION_SUPPRESSE

WF_ACTION_TIMEOUT

WF_CASE_OWNER

WF_CASE_RESULT

WF_CONTEXT

LDAP:

LDAP is based on a client-server model. LDAP servers make information about people, organizations, and resources accessible to LDAP clients. The LDAP protocol defines operations that clients use to search and update the directory. An LDAP client can perform these operations, among others:

searching and retrieving entries from the directory

adding new entries in the directory

updating entries in the directory

deleting entries in the directory

renaming entries in the directory

In LDAP, directory entries are arranged in a hierarchical tree-like structure, starting at a root and then branching down into individual entries. At the top level of the hierarchy, entries represent larger organizations. Under these larger organization in the hierarchy might be entries for smaller organizations. The hierarchy might end with entries for individual people or resources.

Forms:

A form is an object associated with a page that contains rules about how the browser should display user view attributes on that page. Forms can incorporate business logic and are often used to manipulate view data before it is presented to the user.

This form specifies which fields are visible on the Create User page and which HTML form element (for example, text box, check box, or select box) is used to represent each field. This form also specifies

iGATE Sensitive

IdM Quick Reference

additional logic for disabling fields, populating empty fields with default values, and calculating field values from the values of other fields.

Empty Forms:

An empty form is a form that contains no fields that you can deploy to prevent changes from being applied to the User view during form processing.

Resource Form:

The resource form is the form that the administrator selects from a pull-down menu when the resource is created or edited. A reference to a selected form is stored in the resource object.

Resource forms include logic for handling the cases of new and existing users, as well as logic for disabling or deleting the Waveset user when a deletion has been detected.

User Form:

The user form is used for editing from the Waveset interface. You assign it by assigning a proxy administrator to the adapter. If the proxy administrator has a User form associated with him, this form is applied to the User view at processing time.

Default:

Default expression used to calculate a default value for the field. The default expression is called before the form is displayed if the current value for this field is null.

Derivation:

Derivation expression used to calculate the value of a field before it is displayed. It is similar to a Default expression, except that it is evaluated even if the current field value is non-null. The derivation expression is evaluated before the form is first displayed, and then again each time the form is refreshed.

Validation:

Validation expression used to determine whether a value entered in a form is valid. Validation expressions return null to indicate success, or a string containing a readable error message to indicate failure

Expansion:

Expansion expression used to calculate the value of the field after the form has been submitted. Expansion expressions are typically used with fields that are also marked hidden. Since hidden fields are not directly editable by the user, the value can be calculated with an Expansion expression.

Views:

A Waveset view is a collection of attributes that is assembled from one or more objects managed by Waveset. Views are transient, dynamic, and not stored in the repository. The data in a view can change if the view is refreshed to reflect a new role or resource assignment.

iGATE Sensitive

IdM Quick Reference

The most important view is the user view, which contains the user attributes that are stored in Waveset and attributes that are read from accounts managed by Waveset. Some attributes in the user view are visible in the forms that are presented by the Waveset User and Administrator Interfaces. Other attributes are hidden or read-only. Hidden attributes are typically used by rules that derive other visible attributes or calculate field values.

User view:

1) The User view is the collection of attributes that contain information about an Identity Manager user, including:

» Attributes stored in the Identity Manager repository

» Attributes fetched from resource accounts

» Information derived from other sources such as resources, roles, and organizations

2) The user view is most often used with forms that are designed for the pages that create or edit users.

» These pages launch workflow processes that store a changed user view until it is necessary to push the updated view information back out to Identity Manager and associated resources.

» While the user view is stored in a workflow process, the workflow process can manipulate attribute values through workflow actions.

» Workflow can also expose attribute values for user input through manual actions and approval forms.

View Attributes:

A view is a collection of name/value pairs that are assembled from one or more objects stored in the repository, or read from resources. The value of a view attribute can be atomic such as a string, a collection such as a list, or reference to another object.

What Are Standard Resource Adapters?

Standard resource adapters provide a generic interface to resource types that are supported by Identity Manager; such as Web servers, Web applications, databases, and even legacy applications and operating systems. In Java terms, standard resource adapters extend the ResourceAdapterBase class.

Deferred task Scanner:

1) Waveset defines the tasks system property, which is used by the Deferred Task Scanner to cause workflow tasks to be run at some date in the future.

2) A schedulable task "Deferred Task Scanner" needs to be scheduled to run periodically at the desired interval. This task scans through all IDM objects to detect if any task needs to run at the given time, using the date attribute specified while creating the deferred task.

3) The Deferred Task Scanner is a specialized task executor that, on a scheduled basis, walks through all users or resources and launches custom tasks based on triggers

iGATE Sensitive

IdM Quick Reference

Deferred task trigger is in the form of a “tasks” property on the user or resource that stores a list of GenericObjects

Each <Object> (GenericObjects) stores the following information at a minimum:

Which task to run and when to run the task?

You can use the addDeferredTask Session Workflow Service and removeDeferredTask Session Workflow Service to introduce or eliminate deferred task to a user object.

Active Directory:

An active directory is a directory structure used on Microsoft Windows computers and servers to store information about networks and domains.

An active directory (sometimes referred to as an AD) has many functions. It provides information on objects, organizes these objects for easy retrieval and access, allows users and administrators to access it, and allows the administrator to set security up for the directory.

An active directory can be defined as a hierarchical structure. This structure is usually broken up into three main categories: the resources that might include hardware such as printers, services for users such as web email servers, and objects that are the domain and network’s main functions.

Active Directory is subdivided into one or more domains. A domain is a security boundary. Each domain is hosted by a server computer called a domain controller (DC). A domain controller manages all of the user accounts and passwords for a domain.

Difference between Full and Incremental reconciliation:

Full Reconcile is a comprehensive evaluation of Identity Manager Users and all Resource Accounts

-> Typically a first time account seeding step

-> Used to "refresh" the system after downtime

-> Does not trust account index; can fix problems with both users and account index

Incremental Reconcile trusts the Account Index and only processes Accounts that have been added or deleted

-> Much faster than a Full Reconcile by virtue of processing add/deletes only

-> Must still list all accounts on the resource, which can potentially be time consuming

-> Does not detect some situations, like Missing, some cases of Found, and Collision

iGATE Sensitive

IdM Quick Reference

Edited Forms:

1) End User Menu Form:

End User Menu Form controls the display of the main menu in the Identity Manager User interface. Typically, this form contains links for changing the user's password, editing account attributes, and changing answers to authentication questions.

2) Anonymous User Menu Form:

Anonymous User Menu Form controls the display of the main menu in the Identity Manager User interface when an unknown user logs in.

Identity Manager uses the anonymous end user pages for users who are not defined in the system through the process of user self-provisioning. You can customize Anonymous User Menu Form to launch workflow processes to request services before an Identity Manager user exists.

3) Tabbed User Form:

Tabbed User Form is the default form used for user creation and modification in the Identity Manager Administrator Interface. You can customize a copy of this form by extending it with a form of your design.

4) End User Form:

End User Form controls the page that the system displays when a user selects Change Other Attributes from the /user/main.jsp on the Identity Manager User interface.

From this page, a user can change his password, authentication questions, and email address.

You can customize End User Form to grant users control over other fields, such as those that handle phone numbers, addresses, and physical office locations. For example, you can add a field through which users can request access to additional NT groups through the Identity Manager pages.

5) Approval Form:

Approval Form controls the information that is presented to a resource, role, or organization owner when he is designated an approver of user requests. By default, this page displays a set of read-only fields that contain the name of the administrator that started the process. It also displays information about the user, including the account ID, role, organization, and email address.

iGATE Sensitive

IdM Quick Reference

Password Synchronization in Sun IDM 8.1:

PasswordSync:--

You can find this Important Topic in Sun IDM 8.1 Documentation of Business Administration - Chapter - 11

Here I am trying to synchronize password with Active Directory - IDM and Other Resources.

PasswordSync (Tools) detects user password changes initiated on Windows domains and forwards those changes to Identity Manager.

Identity Manager then synchronizes password changes with the other resources defined in Identity Manager.( So that there no need to change the password on everywhere, and through Single User ID and password we can access All Resources which is connected through IDM with Active Directory. - Same Domain Controller..

What is PasswordSync?

PasswordSync feature keeps user password changes made on Windows Active Directory domains synchronized with other resources defined in Identity Manager.

Password Synchronization Tools must installed on All the Domain Controller where Resources will be connected through IDM with Active Directory

And password Sync installation means "lhpwic.dll" file be present on All the Domain Controller Machine.

How it Work--

"lhpwic.dll" DLL receives password update notifications from Windows, encrypts them, and sends them over HTTPS to the PasswordSync Servlets. The PasswordSync Servlets is located on the application server running Identity Manager.

This notification can be send through HTTP:// & HTTPS:// Protocol to the Password Sync Servlets that must present on Sun IDM.

This Transfer has to by 2 Ways:--

1. Direct Methods

2. Through JMS

Direct Method is not implementing every time, it’s for small Enterprise, and where no need to worry about the Message Delivery Notification and this has to be implemented through IDM Native class.

And for the Security and message Delivery Confirmation we use Through JMS, --

iGATE Sensitive

IdM Quick Reference

Password Sync Servlets sends the password information to Identity Manager using JMS (Java Message Service). The Servlets submits password changes to the JMS Message Queue.

Identity Manager’s JMS Listener Resource Adapter checks the Queue for new messages. If a password change message is found waiting on the Queue, the JMS Listener Adapter takes the message off the Queue and imports it into Identity Manager. So that if we have to try password Sync. through JMS Method we must implement JMS Listener in our Existing Identity Manager Environment through Managed resources.

Slow performance seen during checkinView operation:

QUESTION:

While looking into some possible performance issues using the debug/Show_Timings.jsp page, one method we are spending time in is in the com.waveset.ViewMaster.checkinView method.

I've also noticed on this timings page that we are doing a lot of File I/O operations.

ANSWER:

The performance of ViewMaster.checkinView is extremely variable. It depends on the type of view you're using, the forms you're using, and the task that gets launched. In general, checkinView will do the following things for all view types.

1) Run the Expansion expressions in the Form

2) Do view-specific "refresh" processing

3) Convert the view into one or more repository objects

4) Launch a task, often a workflow task

File I/O doesn't normally happen unless you are using a "local files" configuration of the repository. If you are, then you may see I/O during steps 3 and 4. A local files repository is much slower than other configurations; it is useful only for testing and demos.

File I/O can also happen if you have one of the tracing options turned on. Workflow and XPRESS trace in particular can really slow things down, check Waveset.properties to see if any of these are set to true:

exception.trace

xpress.trace

form.trace

workflow.trace

workflow.consoleTrace

iGATE Sensitive

IdM Quick Reference

workflow.fileTrace

provisioner.trace

task.scheduler.trace

Class and method trace enabled in the debug pages can also slow things down.

If you are not using a local files repository, and do not have trace enabled, then the only place file I/O should be happening is in your <Expansion>

Expressions in step 1. Look at the Form and see if any of your Expansions invoke custom Java classes that might do I/O or query a database.

The view-specific "refresh" in step 2 is dependent on the view you are using. Refreshing the WorkItem and Process views has practically no overhead. Refreshing a User view is rather complicated. It generates a lot of garbage and is not particularly efficient, but is usually not significant compared to the overhead of accessing the repository and the resources. This may become more significant if there are a lot of concurrent users.

In step 3, we usually write at least one repository object. Depending on what the underlying database is and the load on it, this may be fast or slow. Usually it is relatively fast.

Step 4 is where most of the variability in performance lies. The task is usually run synchronously, meaning that it will execute to completion in the request thread. For a User view workflow without approvals, this means we may do provisioning which is usually the most expensive part of checking in the User view. If there are approvals, we will execute up to the first approval and suspend the task. This is usually relatively fast unless you have modified the workflow to run database queries prior to approvals.

Checking in a WorkItem view does not launch a process, so it should always be fast.

Checkin of a Process view will launch an arbitrary process, so performance is dependent on what that process does. If the TaskDefinition has an execModeof "async", then it will launch the task in the background and the checkin should appear fast. If execMode is synchronous, the task will execute in the request thread, if it is something like a report or resource scan it could take a long time.

iGATE Sensitive

IdM Quick Reference

What is the difference between an application server and a Web server?

Taking a big step back, a Web server serves pages for viewing in a Web browser, while an application server provides methods that client applications can call. A little more precisely, you can say that:

A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.

Let's examine each in more detail.

The Web server

A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.

Understand that a Web server's delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn't provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.

While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers.

The application server

As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).

Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.

In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application

iGATE Sensitive

IdM Quick Reference

servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques.

An example

As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function.

Scenario 1: Web server without an application server

In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, and then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.

To summarize, a Web server simply processes HTTP requests by responding with HTML pages.

Scenario 2: Web server with an application server

Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server's lookup service. The script can then use the service's result when the script generates its HTML response.

In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.

By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page.

To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.

iGATE Sensitive

IdM Quick Reference

Recently, XML Web services have blurred the line between application servers and Web servers. By passing an XML payload to a Web server, the Web server can now process the data and respond much as application servers have in the past.

Additionally, most application servers also contain a Web server, meaning you can consider a Web server a subset of an application server. While application servers contain Web server functionality, developers rarely deploy application servers in that capacity. Instead, when needed, they often deploy standalone Web servers in tandem with application servers. Such a separation of functionality aids performance (simple Web requests won't impact application server performance), deployment configuration (dedicated Web servers, clustering, and so on), and allows for best-of-breed product selection.

iGATE Sensitive