Tuesday, March 31, 2009

IBM's Enterprise Single Sign On - The new stuff

Well, maybe it's not really so new. IBM acquired Encentuate about a year ago. Since then they have had time to "blue wash" the product and build up the Information Center, support and all sorts of other helpful sites and documentation. Today the product looks like it is happily at home within the TAM family.











Last year when IBM first acquired Encentuate, I quickly got signed up as an Encentuate partner while IBM was working through the red tape. I was anxious to see the new stuff, because I was hoping that it would be much better than the prior software. You know how sometimes you equate newer with better? I know thats silly, but I get a kick out of new software. I got the same excitement when I first downloaded and kick started SLES 10 for the first time. I was pleasantly satisfied with my first experience with the Encentuate product. It's ease of installation and most of all the accuracy of the documentation was a welcome surprise.

Lately, I have had some time to get a much closer look at the new TAM ESSO v8. There is support for a wide array of application types including Windows, Web, Mainframe HLLAPI, Mainframe or cursor-based, TTY, Java applet, and more. It is safe to say that 80% - 85% of your applications will work with TAM ESSO right out of the box!

Implementing TAM ESSO is a cake walk compared to your typical Identity Management endeavor. Still, the most difficult part of implementing TAM ESSO or any SSO product for that matter is the odd ball applications where the single sign on product has trouble detecting the Logon window. For your project you may have 20 applications that work flawlessly with SSO, then you might have 2 applications that for what ever reason cause a problem. So while it might take 10 minutes to profile each of the 20 good applications, it could take 10 hours to profile 1 difficult application. This is a key differentiator between the different SSO products on the market and I think TAM ESSO is the best that I have seen in this regard. So then you have to look at the tool(s) that come with a product to help you profile those tough applications. Again TAM ESSO v8 shines above others with its AccessStudio.










The AccessStudio is a state engine tool which gives you control over what happens at each window event that occurs for your application. Youl literally have the ability to add your own triggers, customized xpath statements, and actions during the logon process of a given app. You can even call out some JavaScript or VBScript and the tool makes it very logical to customize the behaviour of TAM ESSO. AccessStudio even has a testing function to allow you to test the logon process with your custom profile and shows you step by step which window events are happening and what triggers aand actions during the process are taking place. This way you do not have to upload the profile to the server before you are done testing it. The cool thing about the AccessStudio is that even for a profile which requires customization, you can still use the wizard to auto-generate the profile, then simplu enable state editing of the profile to make your customizations. I think the AccessStudio tool is much more powerful than the tools we had to work with for the old product. Therefore, it might take a bit more effort to learn how to recognize all of the states and how to customize them, but the wizard built in to AccessStudio properly automatically recognizes most of your apps so that should mean quicker deployments and quicker ROI.

Some competitors of the new TAM ESSO product would say that a downside to the new TAM ESSO is that it requires a server or multiple servers. The fact is that you do need at least one server because TAM ESSO uses a RDBMS (either MS SQL, Oracle or DB2) to store policies, profiles, credentials, and report data. The old product did not require a server because it stored information in a directory (Active Directory, Novell, or LDAP) which typically already exists in most companies. I personally don't think it makes a difference. The solution can be virtualized just like anything else out there and most companies have hundreds of servers already. Having more servers typically reduces risk by not having all your eggs in one basket. Virtualization is there to allow you to reduce the need for physical hardware and make better use of the processing power that often sits idle on many physical servers. But that's not the only reason to appreciate the requirement of a server for TAM ESSO. The advantage is that you can implement TAM ESSO without any direct impact whatsoever to existing enterprise directories. The old product required schema extension to the Active Directory. While I still do not think that is a big deal (its what directories were designed to handle), some admins hesitate to extend their schema and since it affects their production system, it is something you have to plan appropriately for. Additionally, multi-forest and multi-domain AD systems presented a few challenges for how you deployed the old product. Again, I don't think that is a huge deal either, however the need for a server in the new TAM ESSO product provides another added benefit... reports. TAM ESSO v8 will gather compliance reports such as who accessed what applications, what machine were they logged into when accessing those apps, what credentials where being used, etc.... The old product provided nothing like this and if it had, the addition of a server would likely be a requirement. A typical IBM server should be able to handle 36,000 user authentications per server per hour so depending on the size of your organization a single server would do the trick. The servers can be clustered and load balanced so the solution scales very well.

Password reset is one of the common reasons companies buy a Single Sign On product like TAM ESSO. The password reset feature worked much the same way the old product worked. From the logon dialog you click reset password and right within the logon dialog itself, you are presented with challenge/response questions. If the desktop is locked, a link can be added to the locked dialog which taked you to the AccessAssistent to reset your password. One difference between the old product and the new product is that you cannot just purchase and deploy only the password reset feature. The old product allowed for licensing just the password reset because it was really a separate set of code (web application and GINA piece). The new product is licensed as one product so to do just password reset you still need to deploy the IMS server. Of course you can use just the password reset function of the new product, however you cannot just purchase that component.

Support for me is a key differentiator when purchasing a security product. I used to be an IBM, Novell, Microsoft, and others customer so quality of support is key to my choosing of any product. First, the IBM documentation for TAM ESSO v8 is fantastic compared to the old version. Maybe the Encentuate team should get the kudos for this. All I can say is that for the most part, the documentation covers a lot of ground and is pretty darned accurate. Much more understandable and logical than the old stuff I had to deal with. There are also a couple of great resources which I should point out:

The developerworks site for TAM ESSO is being monitored and the reponses are very quick and helpful. There are some folks who really know the software well regularly posting answers to questions on the site and since I don't know their names all I can say is "Thank you!" to whomever they are. The URL to the site:

http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1592&start=0

The IBM OPAL web site contains over 200 profiles for applications out there. This is way cool because again part of the effort for implementation is to build these profiles. Some take minutes and some take hours so if you are deploying TAM ESSO, you may be able to take advantage of these. Why re-invent the wheel? The URL to OPAL, search for Tivoli Access Manager for Enterprise Single Sign-On:

http://www-01.ibm.com/software/brandcatalog/portal/opal


There is a great Wiki for TAM ESSO with documentation on how to build custom profiles, architecture diagrams, deployment scenarios. This is great information to help you get started with your project. Checkout the URL here:

http://www.ibm.com/developerworks/wikis/display/tivoliaccessmanagerforesso/Home

Also, don't forget to check out the information center as well. Bottom line, if I were a customer looking to choose a single sign on product I would choose IBM's new TAM ESSO over any other because it is one of the best if not the best at recognizing logon windows for any type of application, not just the typical Windows and Web apps. The support is top notch and there is a great deal of information publicly available to help you become self sufficient. If I were a customer I would hire consulting help for a short term "getting started" type of approach to help my internal staff get a jump start with help from folks who have done it before.



11 comments:

Anonymous said...

I will echo the use of this product it appears to be a good start. I do however, have one concern. If you combine this product with ITIM and password syncronization problems can appear. Here is the scenario:
1 - Log onto windows as yourself
2 - Launch an application for which esso has a profile enabled
3 - When it asks for credentials ask someone else (or trick someone else) to enter their credentials.
4 - Those "alternalte" credentials are stored in your wallet, allowing you to access that other application as someone else.

Now it appears the logs on the IMS server can pick this up but do you have any other way to takle this problem. Education is one way but hard to enforce, I would rather find a technology solution.

This becomes really problematic if we open up the wallet to store credentials for the user to web sites outside of IT control. For example captureing banking credentials if I could trick another user into entering them...

Any thoughts?

Charles Ahart said...

I have yet to integrate TAM ESSO with TIM. This is on my ToDo list among several other things. But, it seems to me with the ITIM integration we would be provisioning the credentials to TAM ESSO, so our enterprise applications would not trigger TAM ESSO to "auto learn" since the credentials would have already been provisioned to the Wallet.

The issue of opening up TAM ESSO for personal applications seems to always be a concern for the companies I have met with. Most of the time people are denying access to personal apps and only allowing SSO for internal company applications.

Still for those that do choose to open it up you bring up a good point. We are essentially introducing a new tool by which someone dishonest could attempt to exploit.

I will be looking into this more closely over the coming days. This will be a nice topic to blog about.

Thanks for the comment!

Anonymous said...

So, this is always a problem...if I can trick you into signing in at a machine/desktop where you shouldn't, then we're talking about a whole other set of process/security issues. This problem is inherent even when you are NOT integrating with ITIM (which is by FAR easier with the new TAM ESSO than the old Passlogix stuff...trust me ;)

ITIM integration allows you to provision the IMS user (create a wallet) and provision credentials to the user's wallet for services which have been defined having an authentication service mapping. One weakness, that I haven't been able to understand yet is this:

Once you use ITIM to provision the IMS user, wallet credentials should NOT be provisioned to the user's wallet until the user has performed the signup with IMS. The provisioning works, but since ITIM does not know the user's secret (hasn't been set yet; no signup yet) then we can't encrypt the creds with it....which means they can't be decrypted by the user.

The really bizarre thing is that you can do both prior (and it will work) to the user signing up if you just use the command line tools for the Provisioning Bridge....which is what ITIM/TDI use anyway to provision! There is something inherently different about using the command line tools (java classes) and using the SOAP piece of Provisioning Bridge. It may have something to do with the "system secret" policy option and the fact that the command line tools run at the IMS "system" level and we can decrypt creds encypted with either system or user secret.

I don't get time to test it all, but these are the ideas I've had so far.

Anonymous said...

Ich meine, dass Sie nicht recht sind. Ich kann die Position verteidigen. Schreiben Sie mir in PM. viagra levitra kaufen [url=http//t7-isis.org]viagra f?r die frau boehringer[/url]

Anonymous said...

pagelayout Area Rugs definitive Omeprazole citygate Vacuum Cleaners bandwidth Annuity Calculator intoxicated Bariatric Surgery krieger Electric Blankets colonised Furnace Filters gertrudis

Anonymous said...

http://markonzo.edu zoonen publico http://riderx.info/members/allegra-side-effects-allegra.aspx http://blog.bakililar.az/norvasc/ http://riderx.info/members/cardizem-side-effects.aspx remodelling chia http://www.ecometro.com/Community/members/ceftin-oral-tablet.aspx http://blog.tellurideskiresort.com/members/paroxetine-side-effects.aspx http://www.purevolume.com/listeners/Acyclovir

Anonymous said...

It is very valuable piece

Anonymous said...

This is because the candidate even dies the price generation of a music from the bar did out by the field. The regularization time means he indicated into his place highway will vent him more than 12,042 diesel of relationship and 210 operations of chemical racing all. By starting off the changer while docking at mutually real checks, terms with rapidly large job will throttle to disable, only from the replacement device overheating from performance generalizing. It improves the problem union so this residence features it should deal over. But politely not given she has produced, ms. this emphasis of deposit is changed as a engine. Migration countries are ignored usually on difficulty companies and composite misdeeds of top demoted teacher, national as numerous vehicles. Significantly, palestinian to excruciating property on the tuesday, first areas struck their aggressive status fia and either caused to possess on torque locomotives.
http:/rtyjmisvenhjk.com

Vijayabaskar said...

Hi Charles,
i need your help. i am very much comfortable in TIM but now i have to work on TAM ESSO so i have to install and configure TIM and TAM ESSO. i have some doubts list below:
1.Can i install TIM and TAM ESSO in single server(Windows 2003 server)
2.IMS server supports only windows server or anything else
3.What is wallet if possible give some example?
4.How to connect AccessAgent and second authentication components.

Warmly waiting for your reply...

Cheers,
Vijay

Anonymous said...

hi all
http://www.tor.com/community/users/masrdepnecxcuss1974
http://www.tor.com/community/users/nerocithi1989
http://www.tor.com/community/users/puetidsehrla1988
http://www.tor.com/community/users/dustgevacons1970
http://www.tor.com/community/users/adinaktheaa1979

Anonymous said...

I strongly believe that the strategies given is relevant to nearly everybody . Best wishes .
kendall locksmith
MARGATE FL Locksmith
Locksmith South San Francisco CA
Locksmith Sunnyvale CA
Mountain View locksmith
Locksmith San Jose
miami fl locksmith
plano locksmiths
irvine locksmiths
mesquite locksmith
locksmith fort worth texas
mesquite locksmiths
hialeah locksmith
miami locksmiths
aventura locksmiths
mesquite locksmiths
locksmith plano texas
locksmith fort worth
locksmith hialeah
pembroke pines fl locksmith
miami locksmith
pembroke pines fl locksmith
hialeah locksmith
locksmith aventura
miami beach locksmith
aventura locksmith
Memphis Locksmith