IBM Dropping Tivoli Brand from IAM Suite

I just read this story on Network World about IBM's plans to make Q1 Labs' Security Information and Event Management (SIEM) product, QRadar SIEM, one of the centrepieces of the newly formed IBM Security Systems division. IBM announced the acquisition of Q1 Labs and the formation of the new Security Systems division in the same press release earlier this month.

The news was a bit pedestrian until I read the following:

"IBM is dropping the 'Tivoli' name from the Identity and Access Management suite"

Of course, I did a double-take. As an ex-Tivoli-ean who went around spruiking the virtues of TIM and TAM, I was taken aback. To quote the great John McEnroe:

"YOU. CANNOT. BE SERIOUS!"

Years of goodwill (alright, and some bad when stuff didn't work the way we promised they would - but we always fixed it) and brand awareness thrown away. It also means people will no longer be able to deliver one of these Tim Tams to the customer as a joke instead of actual Identity & Access Management software.

IBM Identity Manager and IBM Access Manager just don't have the same ring. The resulting acronyms are harder to pronounce, and downright confusing, respectively. IIM and IAM. Go around talking about "IIM" and people will think you missed a word and uttered something random in place of said missing word. Either that or they'll ask if you have something stuck in your throat and whether you'd like some water. Talk about "IAM" and people in security will assume you are talking about "Identity & Access Management", not "IBM Access Manager", which only partially fulfils the "AM" part of the real IAM.

This "IIM" and "IAM" talk presents a decent enough segue to the fact that the acronym for IBM's new Security Systems division is "ISS", as opposed to Internet Security Systems (ISS), whom IBM acquired over 5 years ago and then re-branded IBM Internet Security Systems (IBM ISS). The old ISS (Internet Security Systems) technology is no doubt going to be rolled into the new ISS (IBM Security Systems) along with the IAM (Identity & Access Management, not IBM Access Manager) suite that is no longer Tivoli and the Q1 Labs technology.

At this point, you may want to take a break. Your brain must be hurting from that last paragraph...

And, we're back.

While we're on confusing branding, which IBM is no doubt very good at, I'll take this time to note something else IBM is also very good at: bad product names. IBM recently released an add-on to Tivoli, oops, I mean IBM Identity Manager, called Role and Policy Modeler (RaPM). Gees, IBM. Why didn't you just call it "Role and Policy Enforcement Modeler"? I'll leave it to the reader to work that acronym out.

So, IBM, seriously...WTF?

Alas, it is with some sadness that I must now bid adieu to "TIM TAM" and welcome, rather begrudgingly, "IIM IAM". I just said that out loud. Must. Wash. Mouth. Out.

My first identity and access management project

In a previous post (which I subsequently followed up with another), I mentioned the first Identity and Access Management (IAM) project I worked on. I also said I'd follow that post up with more details about the project I mentioned. It's been some time since I said that, but I've finally gotten around to it.

My very first IAM project was an extremely large one. It was for one of the larger Australian federal government agencies and I can't give specifics (or they'll hunt me down) so forgive me if I'm vague in certain parts.

They needed to re-engineer a core, critical business process from end-to-end. This meant a brand new system needed to be built and it ended up taking years. I personally spent almost 2 years early in my IBM career working on this monster as a consultant in the Security and Privacy practice and when I finished serving my time there (reference to prison completely intentional), they were still rolling out other functionality.

My job was done however, because we had finished laying down the whole security framework and it was working in production. The security system was actually very well architected thanks to the fact that it was designed by a very senior, very experienced, absolutely world class enterprise security architect (hi BP, I'm referring to you if you're reading this - probably not though so one of you other IBMers will have to tell him I said hi). This was actually the key. We could have slotted any equivalent product into the architecture and it would have served its purpose. Of course, being strategically aligned with IBM Tivoli meant this was what we used.

The project used a bunch of IBM software: WebSphere Application Server, MQ Series, DB2, some other IBM software to support EDI transactions (can't remember the names anymore) and of course IBM Tivoli Security software (specifically Tivoli Access Manager for e-business and Tivoli Directory Server). We even had full blown PKI software (from another vendor) to support signing of messages (for authentication purposes) and encryption. At the core of this mish-mash of software wrapped with services (provided by a consortium that was not limited to IBM alone) was Tivoli Access Manager for e-business (TAMeb). And what was its primary use? Fine-grained access management or as some of the market likes to call it today; entitlement management.

That's right, I was responsible for implementing fine-grained access/entitlement management in very first IAM project but I didn't know it at the time. Absolutely everything had to ask TAMeb before it could do anything. Want to show a button on a page? Ask TAMeb. Want to show a field on a page? Ask TAMeb. Want to allow someone to process a particular transaction? Ask TAMeb. Can this application send this message to this other application where the message is marked as secret and does it need to be encrypted as well? Ask TAMeb. No application security decisions were made without first making an authorisation call to TAMeb. None of this stuff involved web access management! Sure, we had to implement the web access management aspects too, but this was not the focus. We put in the web access management bits because it was mandated by the security architecture. But this was by no means a web access management project.

From an ease of development, time, manageability and subsequently cost standpoint, having all access control decisions managed centrally made perfect sense. I'm pretty sure everyone on that project would agree with me on this point. Here are a few reasons why they liked having a central access management point:

• All teams could adhere to the same interface contracts when it came to authentication and authorisation. This also meant that if a development team couldn't get a security component working and everyone else could, it was their fault and usually could get it fixed fairly quickly because others knew how to do it properly.
• No one had to write their own security sub-system because it was already sitting there waiting to be used and it worked extremely well. This meant they could spend time worrying about the more interesting things like business logic. I have yet to find a developer who likes writing security code (unless they are building a security product and even then it's debatable whether they actually like what they are doing) because it's simply a hurdle to getting the "real work" done.
• Teams could re-use existing policies if required because they were mostly modelled on a business requirement.
• No need to worry about policy modelling or management of security policies.
• If a policy changed, it would be reflected across all systems. Without a central store, they would each need to worry about how to synchronise their policies so that there weren't any back doors to exploit. This alone is a whole sub-project on its own.
• Security within each system was distilled down to a single statement: "Ask TAMeb". Compare this with having to worry about designing and building a security sub-system, designing and building a way to model identities, roles, policies, resources within the sub-system, designing and building a management layer on top of the sub-system and then worrying about how to ask the sub-system to make decisions from the main application. I'm talking best case scenario here of course because quite often, development teams simply use configuration files which are completely unmanageable (if you've ever written a Java Enterprise application and played with crappy deployment descriptors, you know what I mean). And if you understand the implications of using config files, you'll know that each time a security change is made you have to restart the application (which is going to screw with your SLAs) unless your vendor has some fancy way of dynamically updating in-memory application configuration settings. Oh, I haven't yet thought about how to synchronise security policies with the other systems floating around. Manually you say? Or use a provisioning product? Yeah it's possible. But it also means a heck of a lot more design and analysis work (in the case of the provisioning product). If you want to do it all manually, you can expect to have very frequent security incidents and lots of follow-up meetings with management to explain why it happened.
  

One of the biggest challenges was the huge number of transactions (and as a result, access control decisions) passing through the system due to the sheer size of the project. And to the credit of TAMeb, it scaled well and did the job. Of course, we had to do proper capacity planning and implemented multiple enforcement and decision points (PEPs and PDPs in the XACML world). And the Policy Administration Point (PAP)? This was a combination of the TAM administration console and an application we had to build to perform "identity management". Why did we have to build this? Because IBM hadn't acquired Access360 yet (which became Tivoli Identity Manager) and the existing IBM provisioning product was a piece of crap called Tivoli Identity Director which still relied on the Tivoli Framework (those with experience playing with the old framework know it's EXTREMELY painful).

I should explain why we had to build an "identity management" component on top of TAM. One major criticism of TAM when it comes to fine-grained access management is that it's not very good when you need to add a bit of context that relies on user attributes because:

1. The admin console doesn't give you access to them (last time I checked). To play around with user attributes, you either need to access the LDAP directly or use a provisioning product like Tivoli Identity Manager.
2. Contextual access control decisions based on user attributes are also not the easiest to model without a provisioning product to help. In short, you need to do it based on dynamic role memberships and have policies on resources (or entitlements) tied to these roles. Provisioning products can do this (cater for dynamic roles based on user attributes) out of the box and provision the required changes to the access management product in near real time.

In other words, we had to build the "identity management" piece to allow for contextual access control decisions based on user attributes. Nowadays of course, you can just use your favourite provisioning product.

The glaring omission from the picture is of course XACML. It wasn't even part of the IAM vocabulary at the time and the lack of XACML support in the project makes it very difficult for the government agency to swap TAMeb out of the picture (which IBM definitely isn't complaining about). But I'm guessing it's not a big deal for them because they spent a few million shed-loads worth of tax-payer's dollars to build this system and it works as designed. They're not about to replace the critical security component that makes all the decisions!

The motivation behind my occasional rants about the term "entitlement management" and how it's all too often used as a marketing gimmick to sell more products stems from my time on this project.

Broken record time: call your vendor out if they're blatantly repackaging fine-grained access management as "shiny-new-entitlement-management". If it's more along the lines of what the Burton Group thinks it should mean, we might start to get somewhere. It's still a moving target however, so I'm sure the definition will expand and evolve, especially with all this Cloud crap floating around.

Encentuate blue rinsed

One of IBM's press releases today announces that IDC has named them as the "Overall Leader in Worldwide Identity and Access Management Software".

Frankly, I don't care. Each analyst has a favourite and if you make your purchasing decisions solely based on what your favourite analyst says, you need to have your head examined (yes I know software vendors care about this - remember that I used to have to stand up in front of people and point at slides showing how much selected analysts loved IBM Tivoli). IBM just happens to be IDC's favourite in the Identity and Access Management software market.

I bring this up because buried within the press release is a sub-announcement of sorts:

"IBM also today announced the availability of new IBM Tivoli Access Manager for Enterprise Single Sign-On software, redesigned based on technology from IBM's March 2008 Encentuate, Inc. acquisition."

In other words, IBM have finished "blue rinsing" Encentuate's product which they acquired earlier this year (read what I had to say about the saga here, here, here, here and here).

Interestingly enough, I can't seem to find a separate press release announcing the new version of IBM Tivoli Access Manager for Enterprise Single Sign-On so I'm wondering if they let the cat out of the bag a little early. That said, the product documentation is available so maybe not.

The press release also mentions that:

"Portland General Electric, Oregon's largest electric utility, uses IBM Tivoli Access Manager for Enterprise Single Sign-On and plans to upgrade to the new version 8.0 as part of its security technology strategy to help the utility company drive productivity and save costs on IT and help desk support. The effort has simplified password management for employees, who otherwise could have more than a dozen passwords to access over 20 different enterprise applications."

Two things:

1. Version 8.0?! Did they skip a whole version number? The latest version (up until this point) was version 6.0. What happened to version 7.0? In fact, IBM were quoted as saying version 7.0 would be the first incarnation of the Encentuate product re-badged as IBM Tivoli. So I'm a little confused. It's not a misprint (the product documentation labels it as being version 8.0). So I guess it's just some weird numbering system?
   
2. More importantly, has anyone told Portland General Electric what they're actually in for (read my first post on the acquisition if you don't know what I'm talking about)? I can't seem to find any instructions in the product documentation regarding how to upgrade from version 6.0 to version 8.0 (disclaimer: I haven't read the documentation cover to cover, so maybe it's buried in there somewhere). Are IBM actually going to help people upgrade gracefully or were they just paying customers lip service when they were assuring us that they would make it easy to do so? Here's Nishant's opportunity to suggest Portland General Electric switch to Oracle Enterprise Single Sign-On :-)
   

Update - Phill left the following as a comment:

"IBM has created a dedicated team of project managers and technical consultants to help customers in their migration of Passlogix to Encentuate - free of charge! This team has actually been assembled for sometime and out in the market place transitioning our clients."

It looks like IBM are doing something about it.

Passlogix responds to the IBM situation

There's been many a discussion around the IBM acquisition of Encentuate and what it means. I wrote about it here, here, here and here. I've also received a few emails discussing the issue (mostly with my IBM mates). I've presented the IBM view and an unofficial (albeit tongue in cheek) Oracle view (thanks to Nishant Kaushik). The obvious missing link here is Passlogix's view.

Earlier this week, I received an email from a senior member of Passlogix's management team to open up a discussion and also to clarify their position. One of the topics of conversation centred around one of my posts and specifically my statement:

If you "upgrade" from ITAM ESSO to Passlogix v-GO or Oracle's OEM version of v-GO, you will have to buy the product again. Your IBM licenses will not carry over, unless Passlogix and/or Oracle get very aggressive and agree to "upgrade" your deployment and waive the software costs

The next few paragraphs in orange summarise my understanding (not a direct quote, so it includes some of my commentary) of Passlogix's position.

Passlogix's response is that they are working with every customer running IBM Tivoli Access Manager for Enterprise Single Sign-On (ITAM ESSO) 6.0 (the current version and OEM of Passlogix v-GO) to give them options moving forward and to help give them a choice. They will also honour the existing maintenance contracts that IBM has in place, and if the customer chooses to have Passlogix support them directly, there will be no additional charges to do so.

Passlogix also completely agree with my point that upgrading from ITAM ESSO 6.0 (Passlogix v-GO OEM) to ITAM ESSO 7.0 ("blue rinsed" Encentuate) will be a real pain in the behind because it's a "rip and replace". They make mention of the fact that v-Go is an "infrastructure free/event driven technology" and Encentuate is "server based/script driven". I can't confirm that Encentuate is indeed server based and script driven because I have never seen it in action. If it is, then it will be very painful migrating between the 2 approaches. As an aside, I should point out that it's not surprising that they agree! It helps them keep existing customers. I'm sure every single Passlogix employee is being told to say this. Unfortunately for IBM, I'm right. So IBM, you're going to need to work VERY hard to make it worthwhile for a customer to move to ITAM ESSO 7.0.

One last thing that Passlogix would like to remind us is that if you're the type of organisation that MUST evaluate technology before you can implement it, you'll also have to put up with that pain (as will IBM) before you can migrate to ITAM ESSO 7.0.

IBM will obviously tell you that you do not need to evaluate anything and that it should be treated as an upgrade. How you choose to view it is completely your call. Just be aware that these are the 2 differing views and whichever you pick will have implications for your migration or upgrade plan.

At this point in time, here are your choices:

1. Upgrade to ITAM ESSO 7.0 when it comes out - No additional software license, maintenance or support costs (unless your maintenance contract is expiring). Lots of services pain. Who pays for the services? If IBM doesn't wear most of it, they aren't trying hard enough.
2. Move to Passlogix - No additional software license, maintenance or support costs (unless your maintenance contract is expiring). Services pain will probably be minimal if any. If you have other IBM Tivoli Security products deployed however, keep in mind that future integration points will probably be released for ITAM ESSO 7.0 ("blue rinsed" Encentuate) before Passlogix get a chance to write their integration pieces by virtue of the fact IBM will generally build their integration pieces between internal products first (not always, but this is almost always true within the same IBM product suite). I'm pretty sure Passlogix will continue to support integration between v-GO and the IBM Tivoli products, but they will just be slower in getting them released. There's not a lot Passlogix can do about it of course because they will only be able to build integration pieces into IBM products by working with IBM (unless they wait for APIs to be published, which will make it even slower).
3. Move to Oracle - They'll charge you for the software, maintenance and support (does someone from Oracle want to email me to tell me that you won't?). Services pain will probably be minimal if any. If you have other IBM Tivoli Security products deployed however, this is not a smart choice unless you are ready to throw IBM out and replace your whole Identity and Access Management infrastructure with Oracle.
   

Why did it take this long for someone to build a Web Access Management appliance?

Many IBM Tivoli (and ex-IBM Tivoli) people have been saying for years that IBM Tivoli Access Manager's WebSEAL component should be an appliance, not a piece of software you have to install. For those not familiar with IBM Tivoli's security products, WebSEAL is the web proxy that typically sits in the DMZ of your network and performs the authentication and authorisation for your Web applications. I won't go into a sales pitch about why that's a good thing. If you really want to know, ask your local IBM sales rep or send me an email via the contact form on this blog and I'll get back to you.

For one thing, an appliance will generally perform better. Extremely handy when it's the front door into your enterprise web environment. IBM will not disagree because they have an appliance product doing what WebSEAL does, but for Web Services. It's called WebSphere Datapower, which was technology IBM bought via the acquisition of Datapower in 2005. The specific appliance I'm referring to is the XS40, which I also had to know about for some time until IBM finally decided to stick it once and for all under the WebSphere brand. To be fair, it does have integration points into IBM Tivoli Federated Identity Manager so all you IBM security people shouldn't be ignoring it.

It's also become somewhat of a commodity. Every major vendor has one, calls it "Access Manager", delivers it on a CD (meaning it's software) and all have very similar core functions. They are just architecturally different. I suppose it wasn't worth the effort to make it an appliance even though it made sense. All these "Access Manager" products have been selling just fine as software components.

I've been catching up on my news items (when am I ever not) and stumbled upon these guys. They are P2 Security and have built exactly what I've just described. An appliance that does Web Access Management. They even have a comparison matrix against the big vendors, which by the way isn't exactly accurate. I already see some "crosses" against IBM that I know should be "ticks".

The one beef I have with this appliance from P2 Security is that they count having a policy server as being a negative (see the comparison matrix). I don't see why that is the case? They may argue that it presents management overhead. Sure, but I don't see any mention within their collateral of how they manage security policies when someone decides to buy more than 1 appliance.

If you are in the security game, you know it's a pain in the behind to have to change security policies (or any policies for that matter) in multiple places. Are they saying that if you have multiple appliances, each time you change the policies on one of them, you have to do it for the others? It may be tolerable if it's a simple policy change, but security policies are not usually simple when it comes to authorisation (aka entitlements, although in this case I don't think the appliance can get fine-grained enough to qualify as doing any real entitlement management). Any decent technology company will have an answer for my question, so perhaps they've already thought this through. I just can't find it on the site (maybe I'm not looking hard enough, but it's late so give me a break).

The main point to make here however, is that it remains a point solution. Useful if you are a small organisation that only wants to do Access Management for your web applications, but if you want a more coherent and integrated Identity and Access Management solution, you should probably go for one of the large suite vendors. That said, I applaud P2 Security for delivering what many have been asking for (but vendors have not bothered to build because the ROI on the effort didn't make sense).

Of course, they are a perfect target for acquisition by an Identity Vendor without an access management product. Did I hear someone say Courion?

I wonder if my ex-IBM colleagues will still speak to me

My thoughts regarding the IBM acquisition of Encentuate have been drawing quite a bit of traffic, so I guess it's a topic of interest this week.

Nishant Kaushik, Oracle's Architect for Identity Management Products gives his views on the whole thing including cheekily quoting me. I know it's all in good fun, so I'll respond in the same spirit...although I should ask if they've given him a new role as a member of the sales team? :-) Yes yes I know, the people in the product management/architecture team are evangelists by default, so they have a responsibility to help sell/evangelise their products.

He pinpoints my comments that the upgrade from IBM Tivoli Access Manager for Enterprise Single Sign-On (ITAM ESSO) 6.0 (the current version and OEM of Passlogix v-GO) to version 7.0 (the "blue-rinsed" version of Encentuate) is a "rip and replace". He suggests (tongue in cheek) that instead of going through the pain of upgrading to ITAM ESSO 7.0, customers should "upgrade" to Oracle's OEM version of Passlogix v-GO, the Oracle Enterprise Single Sign-On suite, because it'll be much easier moving forward and...

"could save many an enterprise many a headache."

While that's true in theory, customers could also go the direct route to Passlogix and just upgrade to the next version of v-GO. It's the same product with a different skin. I'm not saying I have a preference for Passlogix over Oracle. I'm just saying you have a choice.

Before you go rushing off and telling IBM where to shove their Encentuate product, the first question you need to ask yourself is, "do I have any other IBM Tivoli security products deployed?" In most cases, the answer will be "yes". If you do, the smart thing to do is to stay calm. Because if you have already invested in other IBM Tivoli security products, it's going to cost you a heck of a lot more to "upgrade" them to Oracle's versions. A "rip and replace" of your core Identity and/or Access Management infrastructure is going to be 1,000,000 times more painful than a "rip and replace" of your ESSO solution. If you only have ITAM ESSO, then maybe you can consider the "upgrade" to Oracle or Passlogix because you aren't as heavily invested in the IBM Tivoli technology. But I know IBM, and I know they will do their utmost to ensure they don't lose their valued customer base...especially over something like a strategic acquisition. I just hope IBM understands the position they have put their existing ITAM ESSO customers in by acquiring Encentuate and do everything possible to minimise the pain (IBM, please don't say "eliminate the pain" because that would just be lying, aka marketing).

Here's more food for thought, especially if ITAM ESSO is the only thing you have implemented from IBM Tivoli. If you "upgrade" from ITAM ESSO to Passlogix v-GO or Oracle's OEM version of v-GO, you will have to buy the product again. Your IBM licenses will not carry over, unless Passlogix and/or Oracle get very aggressive and agree to "upgrade" your deployment and waive the software costs (there's a thought for the sales management team in Oracle and Passlogix, assuming the latter feels like testing their already tenuous relationship with IBM)(UPDATE: Passlogix have responded to me via email in relation to their position. I have written a new blog entry addressing this). IBM will not charge you to upgrade to ITAM ESSO 7.0 if you already have 6.0 and your yearly support and maintenance haven't lapsed. That's just business as usual (assuming IBM haven't changed the policy since I left). The only cost you will likely have to incur as I said before, are the services costs (and any internal, intangible costs to business productivity because of the need to upgrade). If IBM want to keep customers happy, they'll need to somehow subsidise these additional costs. Charging customers the usual fees will not go down well. Remember, Oracle and Passlogix are just waiting in the wings and would like nothing better than to "upgrade" your customer.

So there's the choices as I see them. As a customer, you are actually sitting in a position of power at the moment. You just have to wear the pain of the potential "rip and replace" from ITAM ESSO 6.0 to whatever you choose as the "upgrade". IBM will be nice to you because they want you to upgrade to version 7.0. Oracle and Passlogix (I shouldn't count Sun, BMC, RSA or any other company Passlogix has "gotten under the sheets with" out of the equation here) will want to displace IBM from your environment. Just work out what's best for your organisation in the longer term after careful consideration.

As for my ex-IBM colleagues, the last I checked they were still talking to me, taking my calls and answering my emails. In fact, I know some of them subscribe to this blog (hi guys!). But if any of their existing customers read my previous post (or even this one), they may be getting some irate phone calls asking what IBM is going to do to help them upgrade painlessly and possibly getting yelled at for selling them a product that is essentially about to be "decommissioned" by IBM.

Sorry guys. I'm just telling it like it is ;-)

IBM acquires Encentuate - did they just dump Passlogix?

My former employer (IBM) is at it again. They've made another acquisition to add to their IBM Tivoli Security suite. This time they've acquired Encentuate, which provides an Enterprise Single Sign On (ESSO) solution in conjunction with strong (and multi-factor) authentication capabilities. They also added to the whole story by announcing the "forming of the IBM Security Software Laboratory in Singapore", which to the innocent bystander sounds like IBM are investing in Singapore and also expanding its "research" operations. In reality, it's "IBM speak" for "we just bought a company that had a bunch of developers based in Singapore and we are turning those offices into another 'lab' that we can add to our list of software labs around the world". The whole lab thing is not the point here. I just thought I'd decode that part of the press release for the non-IBM alumni out there.

So who are the ones most affected by this acquisition?

1. Any customer who has bought and implemented IBM Tivoli Access Manager for Enterprise Single Sign-On (ITAM ESSO).
2. Passlogix.
   

For those that are unaware, ITAM ESSO is an OEM of Passlogix's v-GO product suite. IBM did not hide this fact when they first announced the release of ITAM ESSO. The integration points into the relevant parts of the Tivoli Security product suite were built-in nicely once v-GO had been "blue rinsed". It made sense in early 2006 when the announcement was made. In fact, a lot of us internally at IBM Tivoli fully expected Passlogix to be acquired by IBM eventually once the OEM agreement had been fully "road tested" and proven to be a money maker for IBM. I'm sure many Passlogix employees thought the same (I know of one IBM Tivoli employee who left for Passlogix and used the "I would not have made the decision to leave if the company I was going to did not have a real chance of being acquired by IBM" reason in his farewell email).

Halfway through 2006 (not long after the agreement with IBM), Passlogix announced the same thing with Oracle, one of IBM's major competitors in the Enterprise Identity and Access Management space. You don't need to be a genius to work out that IBM Tivoli's management team were not amused.

Passlogix actually also have an OEM agreement with Citrix for use in their solution, although I should point out that this preceded the IBM agreement and only uses sub-components of the v-GO product suite (so I've been told by some of the Passlogix guys). Consequently, the real thorn in IBM's side was the agreement with Oracle.

In other words, Passlogix shot themselves in the foot by hedging their bets with both IBM and Oracle. Sooner or later, one of these 2 giants of the software industry was going to toss Passlogix out the door like a rag doll...although still with a thin thread attached. I don't know why Passlogix didn't see it coming. Let me explain the thin thread analogy.

IBM now finds themselves with an ITAM ESSO product that is essentially a competitor to Encentuate, which they have just bought. They have also sold ITAM ESSO to many customers in the world (if I was involved in selling you this thing, I apologise profusely - I had no idea). Being IBM and with a reputation to uphold, they will still have to support it for customers that have bought it. In parallel, they are going to have to "blue rinse" Encentuate and out of the colouring process will emerge ITAM ESSO! In other words, the next version of ITAM ESSO will be the "blue rinsed" version of Encentuate. What will marketing do with this? Here's my guess:

1. Announce (probably informally - essentially just "socialising" the news to existing customers through the sales teams) an impending upgrade to ITAM ESSO 6.0 (Passlogix v-GO).
2. "Blue rinse" Encentuate.
3. Announce the release of ITAM ESSO 7.0 with new, major functionality including strong and multi-factor authentication, remote single sign on and additional logging and auditing which is integrated with IBM Tivoli Compliance Insight Manager (actually, this last bit will probably be released in version 7.1 because IBM product management will just want to get core 7.0 out the door ASAP).
   

Seamless? Almost. What marketing won't say is that the "upgrade" from 6.0 to 7.0 is essentialy a rip and replace. There is no seamless upgrade. Sure, they'll probably offer some tools to "help", but the upgrade process will need professional services either from IBM Software Services or IBM Business Consulting Services because the single sign on templates will be completely different between the Passlogix and Encentuate products.

Apart from existing ITAM ESSO customers, Passlogix is the other obvious loser. IBM will need to keep its relationship with Passlogix because they still need to support version 6.0 and Passlogix are ultimately the "development team" in this instance. This arrangement will only last as long as customers are on version 6.0 or when IBM decide to stop supporting version 6.0. From memory, upon release of a new version, IBM will officially support the n-1 version for 2 years starting from the date of release of the new version. I don't know if the policy has changed, but if it hasn't this means that the IBM and Passlogix relationship will only last for a further 2 years starting from the release date of ITAM ESSO 7.0.

I can only imagine that Passlogix is suddenly being extra nice to Oracle because it looks like they have just lost IBM as a potential suitor to sell to. It also means they cannot rely on pushing the acquisition price up by hoping that IBM and Oracle start a bidding war. At this point in time, Passlogix have 1 suitor. Oracle. IBM has found something "better" and as a bonus, they just added strong authentication to their kit bag!

UPDATE 1: I just read the Burton Group's reaction to the acquisition and it reminded me that Sun also has a partnership with Passlogix. It's not an OEM one to the best of my knowledge, but Sun could perhaps be a suitor for Passlogix. I still think Oracle's the more likely option however, as Sun has hedged their bets as well because of their partnership with ActivIdentity (one of Passlogix's major competitors).

UPDATE 2: Chris (I don't know his full name because he doesn't publish it) just left me a comment in response to this post to point out that BMC are also a Passlogix v-GO reseller. I actually went back to take a look at Passlogix's list of non-OEM partners and true enough, BMC is on there. If you look down the list, you might also notice that Novell is listed. I don't know if it's a reseller agreement or just a technology integration certification/partnership, but Passlogix are sure hedging their bets even more than I initially thought. I still believe that Oracle are the number 1 suitor and the vendor most likely to acquire Passlogix, but at least having all these partnerships gives Passlogix options if things don't go well with Oracle.

IBM the leader in Identity and Access Management

I didn't say it...not lately anyway (I've previously said it many many many many many times in front of customers). At least now I can prove I wasn't lying :)

IBM are the worldwide Enterprise Identity and Access Management vendor in terms of revenue share according to analyst firm IDC.

They may not be for long however. Oracle just became a very formidable opponent with their acquisition of Bharosa yesterday. Don't get me wrong. I'm not saying Oracle wasn't formidable before the acquisition. But the issue now is that Bharosa does things that IBM's suite does not.

That's right. I said it. An IBM competitor has useful functionality that IBM Tivoli does not provide (here comes all the abuse from my ex-IBM colleagues).

More on this later.

IBM responds to Oracle with Mickey Mouse monitoring tool

Before I start, I should point out that just because I no longer work for IBM does not mean I dislike IBM. I still have a great respect for "Big Blue" and will continue to do so until they do something that radically changes my mind. I say that up front because I'm about to be somewhat critical of them. I've always had my criticisms of the company, but now I can raise them in a public forum (instead of privately discussing them with my colleagues) without fear of having management "give me a stern talking to"...now I just have to put up with comments from my former colleagues. But a little healthy discussion never hurt anyone.

I am referring to the new monitoring offering from IBM Tivoli, specifically around the Identity and Access Manager products. The monitoring offerings can be found here and here. I'll probably get a little grief about this from those of you I know from IBM. Hey, I'm entitled to my opinion aren't I? Especially as I talked about Oracle's offering earlier this month.

Before I move on, I'll take a little detour and talk about IBM from a marketing standpoint. I used the term "respond" in the title to this post, but I'm not sure that's the case. I was simply referring to what the average person would perceive it as. As far as marketing and image is concerned, perception is the truth. Oracle made their announcement early in February. According to IBM's pages, the monitoring offerings were released mid to late January, which is before Oracle's announcement.

So it looks like it was being developed at the same time as Oracle, unless IBM have managed to trick those of us delving deeper into believing this is the case by listing the release dates in January. I don't know because even internally within IBM, there was no announcement to the greater community until my last week at IBM (week ending February 16)...and I worked for the field sales team whose job it is to sell the software and use announcements like this as "value add selling points". And herein lies the problem with IBM marketing when it comes to Identity and Access Management. If they do such a poor job of communicating this information internally (in a timely manner), how are they to do this effectively to the external audience? This lends itself to a belief I've had for as long as I've worked in this area.

The biggest barrier to sales and building a long term pipeline (even one that the sales people cannot see) and dare I say shortening the sales cycle (apologies for using all these sales "buzzwords") is that IBM is behind the eight ball when it comes to mind share in the Identity and Access Management arena. When it comes to enterprise identity, the press is filled with references to Oracle. When it comes to user centric identity, it's all Microsoft (and occasionally smaller niche players like Sxip and JanRain). Lately, even Symantec's getting into the act.

It never used to surprise me when people would look at me with bewilderment when I told them IBM was one of the leading vendors in this space. It still doesn't surprise me. IBM's PR and marketing machine does an extremely piss weak (i.e. very poor) job of talking up its Identity market leadership. It spends too much time harping on about Linux, Open Source, SOA and the services offerings from Global Business Services and Global Technology Services (at least I think that's what they're called now - they keep changing the names and re-organising the business units, and I have first hand experience that confirms how confusing it is even for employees). Even with these headline messages, they send out mixed signals!

Now that I've got that out of the way, back to the topic at hand. I'll be the first to admit that I don't know the deep technical details of what Oracle's offering actually does. I only know what I've read at a high level. At face value, it looks like Oracle's offering does more than IBM's. I won't outline the details because you can go read about it yourselves (unfortunately, the only link I can provide is this one to the announcement - Oracle's site is so crap that I couldn't find any specific information about their monitoring offering for identity management). I linked to IBM's offering earlier in this post but here are the links again if you don't want to scroll (here and here).

The monitoring offering from IBM tracks the following in Tivoli Identity Manager (TIM):

• Server availability and server process activity
• memory usage characteristics: heap size before and after garbage collection, max heap size, garbage collection time
• workflow queue backlog
• user page response times
• tablespace usage
• logged error messages

And the following in Tivoli Access Manager (TAM):

• Server availability and server process activity
• WebSEAL statistics
• Junction statistics
• response times
• workload

Here's why I think these features are "Mickey Mouse" in nature. Most customers I know who have implemented TIM and/or TAM and want to monitor the identity infrastructure has had to implement it themselves (because as I have previously said, there was no actual solution provided by IBM for it). How did they do it? Shell scripts that take a day or so to write. Pretty trivial stuff because they just wanted to monitor infrastructure statistics like performance, server load, response times, table space usage etc. But hang on, that looks like what IBM's just provided as the monitoring offering! All IBM have done is hooked it into the IBM Tivoli Monitoring product set via the Tivoli Universal Agent! If I were a customer, I'd still write my own and let my shell script feed the data into the relevant standard monitoring infrastructure within the organisation's environment.

Of course, IBM usually doesn't do things without a few good reasons. In this case, it is possibly for the following reasons:

• They knew what Oracle was doing and didn't want to be seen as falling behind.
• IBM customers have been calling out for a monitoring solution to deal with the IBM Identity Suite for over 2 years and they decided to finally address it (in a half hearted sort of way). In other words, the sales team can finally say "yes" without looking guilty when customers ask if there's a monitoring solution for the Tivoli Identity and Access Management suite.
  
• It's a good way to up-sell customers who have the Tivoli Identity suite and get them to consider the Tivoli Monitoring suite.

Of course, that's not to say it doesn't have any real benefits. Problem is, I can only see 2:

• Customers no longer have to write their own shell scripts to do this.
• IBM services teams and IBM business partners no longer have to write scripts when they deploy the Tivoli Security products to deal with monitoring. Of course, any good services team will have already written the scripts and should just re-use as much of it as possible, so one could argue whether this is a benefit here. It's probably more beneficial for teams who are new at deploying the products.
  

As for the biggest barriers to adoption:

• This is useless to me unless I have IBM Tivoli Monitoring.
• I cannot modify the solution for my own needs...at least not easily.
• Where is the monitoring offering for the underlying identity infrastructure? By that I mean the most important software support component used by TIM and TAM - IBM Tivoli Directory Server (TDS)! TDS is the LDAP component so one could argue that you could go find some open source alternative or find some LDAP monitoring solution out there. This defeats the whole purpose doesn't it? IBM's solution lets you monitor TIM and TAM for "infrastructure things" but doesn't actually let you monitor the core software components supporting the applications. So the answer is to use the new offering for TIM and TAM but go build your own or buy something else to monitor TDS? Sounds rather nonsensical to me. I may be over reacting here because monitoring an LDAP is not difficult. It's common and pretty standard practice. TDS even has a section of the LDAP tree that can be queried for monitoring stats. Problem here is that I've still got to somehow feed that into my monitoring solution. Back to writing scripts I guess! To illustrate this point, let me just point one thing out. TIM and TAM don't work without TDS. Enough said.
• It only monitors trivial infrastructure metrics. There is nothing that will give me the business context I need, which is often the biggest reason to monitor the security and identity infrastructure.

Here's a few examples of what I mean when I say business context monitoring:

• Repeated failed authentication attempts.
• Tracking a user's session to alert of suspicious behaviour.
• Alerting of requests for access to "sensitive" parts of the environment (systems or additional access to what a user already has).
• Real time alerts of additional access privileges that do not meet defined security policies (an email to a person hoping they'll see it soon doesn't cut it I'm afraid).
  

The list is endless...and will be very different for each company, especially when dealing with business processes around auditing and compliance. Don't get me wrong. IBM Tivoli (and possibly even Oracle) has the products in place to address these needs. There just hasn't been a combined solution that solves these issues easily. There's too much services and customisation work involved and not enough "cookie cutter" approaches to make life easier for end users and services teams. And here is where both Oracle and IBM have not addressed a real need.