Tivoli Identity Manager Architecture

The Tivoli Identity Manager Server application runs on IBM WebSphere Application Server and communicates with adapters on remote systems.The Tivoli Identity Manager application runs on a single-server configuration with the WebSphere Application Server base product. However, Tivoli Identity Manager can also run in a larger cluster configuration that is composed of one or more WebSphere Application Servers and of a deployment manager that manages a cluster.

Tivoli Identity Manager stores transactional and historical data in a database server. For example, the Tivoli Identity Manager provisioning processes use a relational database to maintain their current state and their history. A type 4 Java Database Connectivity driver (JDBC™ driver) connects the Tivoli Identity Manager Server to a database. The DB2 and Microsoft SQL type 4 JDBC drivers are bundled with the Tivoli Identity Manager installation program. For an Oracle database, you must obtain this JDBC driver (ojdbc14.jar) from your Oracle Database Server installation.

Along with using a relational database, Tivoli Identity Manager stores the current state of the managed identities in an LDAP directory, including user account and organizational data. It is always recommended that Tivoli Identity Manager has its own database and LDAP server, due to the high volume of data exchange between these two components and Tivoli Identity Manager Server.

Finally, an HTTP server, such as IBM HTTP Server, and an IBM WebSphere Web server plug-in enable browser-based access to the Tivoli Identity Manager Server.

 Click on the figure to zoom

 

The above fig illustrates that Tivoli Identity Manager supports the use of two type of adapters:

Agent-based adapters, which must reside on the managed resource to administer accounts. Communication between adapter and Tivoli Identity Manager Server is usually through DAML protocol. So, these adapters are often called DAML-based adapters.

Agentless adapters can reside on a remote server to administer accounts. For example, the UNIX/Linux adapter is an agentless adapter.

IBM Tivoli Directory Integrator is an optional installation component that is used for hosing of agentless, RMI-based (Remote Method Invocation) adapters. The tool is also used for complex HR feeds (a load of person data into Tivoli Identity Manager) from typical resources or from multiple resources. Tivoli Directory Integrator can be installed on a separate server (usually called Adapter server),or it can be co-located on the same server that runs WebSphere Application Server and Tivoli Identity Manager Server.

The RMI Dispatcher is a Tivoli Directory Integrator component that enables the Tivoli Identity Manager Server to communicate with a Tivoli Directory Integrator-based adapter using RMI. The RMI Dispatcher is the request handler inside Tivoli Directory Integrator for the Tivoli Directory Integrator-based adapters. The RMI Dispatcher is not installed with the base Tivoli Directory Integrator product and must be installed separately in order for the Tivoli Directory Integrator-based adapters to run.

Directory and Database

Though both directory and database are considered as organized collection of data, they have subtle differences.

A directory is optimized for read operations. To query any data from a directory we use an application protocol called LDAP (Light weight directory access protocol). This protocol is used specifically for querying data as well as modifying said data. Examples for LDAP Directory: Active Directory, Tivoli Directory Server, Oracle Internet Directory

A database is optimized for write and change operations. Originally, databases were flat. This means that the information was stored in one long text file. Each entry in the file is separated by a special character, such as a vertical bar (|). Querying data from such flat files made our job cumbersome.

Then in 1970’s the 'Relational database' came into picture which uses tables to store information. Relational databases are created using a special computer language called structured query language (SQL). SQL is the foundation for all of the popular database applications available today. Examples for Relational Database: Oracle Database, DB2, Microsoft SQL Server

Therefore, any data that is read many more times than it is written or modified is a good candidate for storage in a directory.

Web server and Application server

A Web server can execute only Web applications.The Web applications are usually stored on a server and delivered to users over the Internet. The Web server takes the HTTP request, then passes it to a server-side program (Servlets, JSPs, ASPs, CGI Scripts...) to handle the request. Once processed, the HTML response is sent back to your Web browser.

In short web server simply serves pages for viewing in web browser. Examples: Apache Web server, Google Web server

An application server is capable of executing Enterprise applications.It can act as a simple Web server or can run Enterprise business logic.For example, a J2EE application server exposes the business logic through a component API (Such as an Enterprise JavaBean component).Then a client application program (Say a GUI running on a PC, a Web server, or even other application server) can employ this exposed business logic however it wants.

It implies an application server can support HTTP,TCP/IP and many more protocols.In addition, application server also has extra features like security, transaction processing, resource pooling and messaging. Examples: Websphere, Jboss, Weblogic