Changing from one security stack was a little bit like a musician switching from playing guitar to keyboards. Many of the basic concepts are the same but it did take a while to figure out how you actually do things in the new environment. Functionally OIM and TIM are very similar. There are very few business processes that you can support in one product and not in the other. On the other hand there is a number of things where the architecture or the implementation hinders or helps you substantially compared to the other product.
One example where OIM and TIM have different approaches is deployment architecture.
OIM uses a very standard physical deployment architecture with webserver, appserver, application and database. Most of the business logic configuration gets implemented by configuration changes and Java extensions deployed on the application server.
TIM uses the same basic structure but splits the data storage layer between a database and an LDAP server. Most of the business logic implementation is done inside of TIM either by straight configuration or by adding Javascript "scripts" into hooks in the GUI.
There are advantages as well as disadvantages with the TIM approach. The biggest disadvantage is that there is another critical piece of infrastructure that you need to support. As the LDAP server also needs a db you may end up having to support an Oracle DB and a DB2 instance for the Tivoli Directory Server. Not fun.
There are advantages as well as disadvantages with the TIM approach. The biggest disadvantage is that there is another critical piece of infrastructure that you need to support. As the LDAP server also needs a db you may end up having to support an Oracle DB and a DB2 instance for the Tivoli Directory Server. Not fun.
Aside from the support issue the LDAP server means that you end up with a large number of servers in an enterprise grade no single point of failure install. As it generally really isn't advisable to run a DB2 and an Oracle DB on the same physical host due to memory footprint you suddenly need four data layer hosts. High hardware costs, lost of energy and cooling and many servers to patch.
The problem of server sprawl is further increased by the fact that you really need to make your final testing environment as similar as you can afford to your production environment which means that it also should have full high availability. There you have another four servers just for the storage layer.
The problem of server sprawl is further increased by the fact that you really need to make your final testing environment as similar as you can afford to your production environment which means that it also should have full high availability. There you have another four servers just for the storage layer.
The advantage of the LDAP approach is that the users and their base data is easily accessible through LDAP calls which makes implementing certain business processes such as "warn manager about contractor that is about to expire" very easy to implement. It also means that you can peek into the user information using an LDAP browser instead of a SQL client which may or may not be nicer depending on your personal preferences.
Nice write up. I am sure you have more on these topics. I dont know about TIM, but you gave a nice intro that even we cant find in the documentation of these products.
ReplyDeleteAlso, can you please write more about how Java used in TIM? Is it same extensively like OIM, or is it different?
Cheers,
Vijay Chinnasamy
Nice Writeup
ReplyDeleteThis shows how deep understanding of the product u have.
Cheers!!
-Mukul
From a Implementation point of view, TIM is a easy to implement when compared to OIM in achieving some of the standard features of IDM. In TIM , TDI makes the connector development very quick and very easy as compared to OIM where we need to write a java code. Where as TIM does not have an option of extensive java code usage as in OIM, which gives OIM great flexibility in achieving the goals, how ever ITIM provides the option of using java code. How ever there are API's provided in ITIM which can be used for higher level of customization.
ReplyDelete