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.

The Problem With Application Security

I've been pondering this for some time and wondering why it's so difficult to get application developers and software architects to care about security. Then it hit me:

They don't care to understand enough about security to care about it.

Recently, I talked to a VERY senior software architect who is in charge of a project for a VERY large company. The project deals with moving information between various data sources. One of these sources is the physical access control system. In other words, the component doing the moving of information would be a primary candidate for a hack should someone want to get somewhere in the building they weren't supposed to be.

Me: "What about security?"

Architect: "We encrypt the source data file that gets read."

Me: "And what happens when the data is being passed around between systems?"

Architect: "It's all on the internal network. We don't need to worry about security since it's all trusted."

Me: "So, there's no need for you to even ensure data integrity?"

Architect: "Why? What for?"

Me: "What if someone messes with the messages being passed back and forth between the systems?"

Architect: "Why does that matter?"

Me: "An attacker could change it while the data is in transit."

Architect: "That won't happen."

Me: "Shouldn't you at least sign the messages containing the data? It doesn't take much code to do it."

Architect: "No, we trust everything internal."

Me: "Does your project have anyone who is responsible for security?"

Architect: "I am."

Enough said.

Product Naming Confusion

You marketing types responsible for the constant renaming of your sub-brands in recent years (and are probably still doing it) have a lot to answer for. It's caused me a few headaches recently and I dare say lots of others that just haven't bothered to voice their displeasure.

It wasn't so long ago, that many of the large Identity & Access Management (IAM) vendors had sub-brands under their sub-brands before you even got to the real name of the product. That is no longer the case, but it's still a problem that will continue to hang around as long as we have marketing departments and products to sell. Many of the large vendors still do it, some with good reason. But most of the time, it just causes confusion.

What am I talking about? In the IAM space alone, we had IBM Tivoli SecureWay, CA eTrust and Sun ONE, to name a few. Take what is now known as Tivoli Access Manager. Back then, it was known as IBM Tivoli SecureWay Policy Director. Tivoli was better known as a systems management brand in those days, so the "SecureWay" brand made it clear that Tivoli had a set of security products.

What's beginning to happen now however, is that organisations that have legacy applications from those days and have not upgraded still refer to product by the old name, which would be slightly easier to deal with if everyone used the full name. Unfortunately, no one ever does for the sake of brevity.

Now, I'm not going to name any particular company as this could have happened with any of them. For this reason, let's take a hypothetical company, SCI, with a sub-brand called Onetiv, and yet another sub-brand of the Onetiv sub-brand called TrustWay. SCI, being a large software vendor, has lots of products. But it is quite well known for its SCI Onetiv TrustWay DodgyStandardWidget product, which has a standard, open interface called the DSW protocol. SCI has a few other products under the TrustWay banner which are still commonly used, but not as well known.

An organisation, DodgyBrothers, which uses one of SCI's products, has an external consulting team working on specifying a project which has to integrate with the SCI product in question. In the project specification, it states that DodgyBrothers uses SCI's TrustWay product. If you've been following this story along, you should be saying:

"Hang on a minute, which TrustWay product?"

But imagine I hadn't given you the background and that in your mind, you only know of a single TrustWay product: DodgyStandardWidget. Now, place yourself in the shoes of the technical analyst on the consulting team working on the specification for the project. The next line you write is going to say something along the lines of:

"And the integration into TrustWay is done via the standard DSW protocol".

Based on this project specification, an agreed statement of work was signed between DodgyBrothers and the external consulting company to implement the solution with a set of agreed timelines (based on project estimates derived from the specifications). Along comes the design team who then reads through the specifications and then proceeds to design the solution. As part of the design, the architect needs to talk to relevant teams within DodgyBrothers to gather information regarding each integration point.

When it comes time to speak to the TrustWay team, the architect is greeted with the response:

"What do you mean by DSW protocol? TrustWay doesn't support the DSW protocol."

The architect then asks the TrustWay team to send any documentation they have on the TrustWay product. Upon receiving the information, the architect is horrified to read the title on the first page: "SCI Onetiv TrustWay NotSoDodgyOtherThingy". The architect thinks:

"Maybe it's not so bad, perhaps it uses the DodgyStandardWidget product as the underlying store. Nope. Next. Ok, maybe there's an interface we can leverage to integrate with this thing. Nope. Now what? Oh, command line. S*$%."

I don't need to tell those of you with project experience what just happened. Project plan, blown out. Cost, blown out. Budget, gone. Change request? Let's hope the client agrees. Unlikely. It was the consultant's fault for not doing their homework. Or was it?

Yes, the technical analyst is to blame for not being thorough (due to an assumption they had no reason at the time to think was incorrect). But anyone responsible for using sub-brands, swapping them in and out and constantly renaming products thus confusing the heck out of customers has to accept some of the blame too.

Me? I'm just annoyed at having to be the one doing the due diligence after the fact and be left holding the lump of crap after you've all run away. Thanks.

How BrowserID works (in Federated Identity terms)

The point of this post is to delve a little into how BrowserID works in the context of what those of us in the Identity & Access Management (IAM) world understand as Enterprise Identity Federation. I'm NOT advocating that BrowserID be used in place of SAML (or any other Federation protocol). I'm merely trying to put on my IAM-glasses and taking a look at the flows in a BrowserID environment.

If you want a less technical, introductory view, read my previous post relating to BrowserID.

Here are the important parts of the "BrowserID dance" and how they map (roughly) to the common terms we understand in the IAM world:

• Email Address - Persona
• Relying Party - Service Provider (SP)
• Email Provider - Identity Provider (IDP)
• Web Browser - Identity Proxy (I know there's not a common definition for what an Identity proxy is but this is the closest I could think of - better suggestions welcome)

Mozilla has specific terms for each of the components, but I've used more commonly understood references to make things a little less confusing. For example, the web browser is officially the "Implementation Provider" in the BrowserID world. Mozilla uses a generic term to allow for the use of something other than a web browser as the medium for accessing an Internet service (e.g. a mobile or desktop client).

The way a relying party validates that you are the rightful owner of an email address is by validating the assertion that is presented along with it. The assertion uses proper cryptographic mechanisms and hence is fairly secure in terms of one NOT being able to generate a valid assertion without being in possession of the relevant certificate (of course, if your browser is compromised, all bets are off). The assertion is signed by the email provider (which as I've pointed out above, is the IDP in the whole scheme of things).

Sound familiar? If you have experience with Enterprise Federated Sign-On concepts, the notion of signed assertions should be second nature to you. The main difference here is that the signed assertion is stored in the browser and presented to the relying party by the browser without necessarily having to interact with the email provider (the IDP). The relying party is then expected to validate the assertion with the email provider before allowing the user access. In a typical Enterprise Federation scenario, the browser is simply a facilitator of information and interactions between the IDP and the SP.

Using Gmail as an example, the (simplified) flow to sign in to myfavefictionalsite.com (obviously not a real site) using BrowserID would go something like this:

1. Visit myfavefictionalsite.com and click "sign in with BrowserID".
2. If your browser is clueless about your Gmail email address, it will ask you for it (if it already knows about your Gmail address, skip to the next step). Once you are signed in to Gmail, the browser will do the "BrowserID dance" with Gmail to get an assertion provisioned to (stored in) your browser for your Gmail email address.
   
3. At this point, your browser knows about your Gmail account and has a valid assertion. It will pass the assertion to myfavefictionalsite.com and you will be registered (if you are a new user) and signed in (after myfavefictionalsite.com does whatever it needs to do to validate your assertion).

Sound simple? Yes, but as always, the devil is always in the details. For BrowserID to work this way, the email provider (Gmail in the example) needs to support the "BrowserID dance". Gmail does not. In fact, I don't know of any email provider that currently supports BrowserID.

This brings me to the fall-back option, which is how the prescribed demo site (http://myfavoritebeer.org/) works. BrowserID has this notion of "Secondary Identity Authorities". The email providers are known as "Primary Identity Authorities". If the email address you are trying to use belongs to a provider that does not support BrowserID, the use of a "Secondary Identity Authority" is used. At the moment, the default is browserid.org.

Mozilla states that anyone can be a "Secondary Identity Authority" if they so choose. A "Secondary Identity Authority" is supposed to hold user information (e.g. username, password, email) and also facilitate the process required to validate ownership of an email address. The typical way to do this is to send the user an email with a validation link which the user must visit. Only when the URL within the link is visited can an email address be designated as valid. In essence, a "Secondary Identity Authority" is an IDP which validates that your email address is actually "owned" by you and also signs you in.

Because there are no email providers today that support BrowserID, the only way a user can sign in using BrowserID is by using a "Secondary Identity Authority".

The best way to understand this is to try signing in to Mozilla's My FavoriteBeer demo. When you attempt to sign in, you will be asked for an email address. The demo's sign-in prompt will wait there until you check your email and click the validation link. Doing so validates your email address and the demo site will proceed to log you in.

I've tried to keep things in this post at a fairly high level in terms of technicality. If you're interested in getting your hands a little dirtier with the flows and specific interactions, the best description I've come across of how BrowserID hangs together is by Lloyd Hilaiel, who works for Mozilla and is responsible for the My FavoriteBeer demo. It's quite detailed and should give those of you interested a lot more "guts" than I have here.

Finally, my previous BrowserID post mentioned a few issues. But I've just come across a question about BrowserID in the IT Security section of StackExchange that has answers which bring up a few more more valid technical issues. Check it out if you're interested in that kind of thing.

Blog RSS feed strangeness

If you're a reader of my blog via the RSS feed and use Google Reader, I've noticed it's doing something strange.

There was only one published post yesterday/today before this one and it was titled "BrowserID - The browser as a Federated Identity proxy" and should appear immediately after this in the RSS feed (and obviously on the web).

For some reason, the RSS feed is publishing 2 additional posts that I had in draft and have since deleted:

1. BrowserID - The browser as a Federated Identity proxy (part 1)
2. BrowserID - The browser as a Federated SSO proxy (part 2)

Please ignore them. If you follow the links through, you'll notice the pages don't exist. I've since turned part 1 into the aforementioned "BrowserID - The browser as a Federated Identity proxy" post which was published. If you happened to read what was to be part 2, you've basically been given a preview of a follow up post I'll publish right after this (update: I've since published the follow up post here).

Apologies for the issue. There doesn't seem to be anything I can do about it. If I had to guess, I'd say there's some Google Reader caching strangeness happening here.

BrowserID - The browser as a Federated Identity proxy

The latest and greatest piece of technology doing the rounds looks to be Mozilla's release of BrowserID into the wild. It's even attracted a fair amount of interest outside the Identity & Access Management (IAM) community.

Mozilla pitches BrowserID as "a better way to sign in" using your email address and from the bits and pieces of commentary I've read, a fair number are raving about how great it is. Of course, there are also doubters and the most common question being asked is how it's different from OpenID. In fact, it's such a common question that Mozilla's already posted an official response.

To simplify it, all BrowserID does is validate (or assert) that you "own" the email address being presented to the service (e.g. a website you need to sign in to) being accessed. Whether the service chooses to accept it as a valid credential is completely up to the service in question. It ultimately comes down to trust and whether a service wants to allow you to use a particular email address to sign in. In this respect, it's not much different to using OpenID to sign-in to a site.

Mozilla's response to how BrowserID differs to OpenID touches upon some valid points. But the main advantage BrowserID potentially has over OpenID, is in its ease of use. It benefits mainly from being tied to the web browser, although Mozilla states that this does not need to be the case down the track. I should stress that a lot of the supposed usability benefits are theoretical at the moment because the primary method for using BrowserID is currently not implemented (more on this in a few paragraphs).

Usability in Identity matters (particularly when it comes to consumers) has always been key. If the act of registering or signing in is too confusing or difficult, people will not use it. The fact that Mozilla is trying to make everything happen transparently (and securely) through the browser means that if they get it right, there is very little the user has to do. No longer will users have to constantly get jolted from site-to-site while they complete the "Federated Single Sign-On dance". For someone who does not understand what is going on, it is a very jarring experience and the industry has yet to solve it properly. The closest we've been able to get is Facebook Connect and arguably Twitter's OAuth experience. But we owe the success of those efforts more to brand recognition than any real improvement in the user experience.

In addition, if something is difficult to implement from a development perspective, there is no chance of user adoption because the functionality in question will never see the light of day. I've personally done quite a lot of work in the past 2 years with OpenID and OAuth within a relying party (a service that accepts identity credentials from a separate, trusted site) and it's not the easiest thing in the world to get right. There are various libraries around to make the implementation less painful, but after taking a look at the source code for Mozilla's BrowserID demo site and the way one enables BrowserID within a relying party, I have to commend them for making it easy (side note: Facebook Connect's success can also be partially attributed to the fact they make it easy for relying parties to embed Facebook Connect functionality within websites).

BrowserID-enabling an email provider however, is much more difficult. There is currently no nice, easy way to do it. I'm guessing Mozilla will get around to making this easier in time. Also, email providers are typically large companies (e.g. Google, Yahoo, Microsoft) so if they really wanted to BrowserID-enable their email service, they will find a way to do it irrespective of any difficulties. But therein lies the challenge for BrowserID; getting email providers to support BrowserID. Without their support, BrowserID has to rely on what Mozilla calls "Secondary Identity Authorities", which are essentially email validation services that hold user account details for sign-in purposes. For example, a "Secondary Identity Authority" requires that you sign up for an account with it so it becomes your Identity Provider in the event that your email provider does not support BrowserID (which at the moment would mean 100% of the time). It also performs the sending of emails to your specified email address to verify that it belongs to you before it will allow you to use it to sign on to a relying party. As of the time of writing, the only known "Secondary Identity Authority" is Mozilla's browserid.org (which means it will probably be the default "Secondary Identity Authority" moving forward).

A glaring weakness those of us in IAM will notice with BrowserID is the apparent lack of any way to pass user details from the email provider to the relying party. This may not be a problem in cases where the relying party doesn't need to know anything about a person, but in situations where the relying party wants to store details about a person, they still need to go through a registration process instead of having information approved by the user sent as part of the federated provisioning process (which OpenID, OAuth and Facebook Connect are capable of doing - I'm ignoring SAML on purpose for now because it would be like comparing apples with oranges).

One major issue I noticed was that once your browser has an assertion that you own a specified email address, you are no longer prompted for validation (until I assume the time the assertion expires). I'm not entirely sure if this is just the way it's been done for the demo or if it's the expected norm, but this is bad. Very bad. It may be convenient, but I don't believe the benefit outweighs the security risk posed. Why? Because it gives anyone with access to your web browser full access to all the sites you use BrowserID for without having to know your password. You are simply asked which email address you want to use and if the relying party site accepts it, you're in! Bad bad bad! I'm not aware of any written guidance by Mozilla on when assertions should expire (although I must admit I have not read ALL their documentation), but I hope email providers choosing to support BrowserID set short assertion validation lifetimes.


It's still very early days for BrowserID so it's difficult to be too critical. They're off to a decent start, but do we really need another way to do Federated Sign-On where the main difference is that the browser plays a more critical role? I'm not sure we do. Could we not do something similar with browser plugins built to support OpenID or OAuth? We'll just have to see where Mozilla go with this. If they manage to make registration and sign-on dead simple, perhaps they'll be in with a chance.

Does the average person care about personas?

Earlier this week, ReadWriteWeb wrote about Google's plans to launch a new service called Circles. They didn't quite get the launch date right, but it looks like it's a real product that Google will release pretty soon.

The article embeds a great presentation by ex-Googler, Paul Adams who now works for Facebook. I completely skimmed over the presentation (i.e. didn't even know it was there) while reading the original article, but came across it again thanks to Jonathan Sander's tweet.

It's quite a lengthy presentation but well worth the read. Essentially, it talks about how current social networking services (like Facebook) don't really reflect how we behave in real life where we have various personas (e.g. one for family, another for friends and yet another for colleagues) which we present based on the context of the interaction we're having.

This is not the case in most online interactions. On Facebook for example, everyone is a "friend". It's rather difficult to share things with subgroups. It's not impossible, but it's very fiddly and time-consuming. That said, there are things we simply cannot share ONLY with a subset of our connections. For example, I can be quite picky with who sees my photos but my status updates go out to all my "friends". Side note: I underlined the word "sees" in that last sentence because your photos on Facebook aren't actually private. They control visibility on your photos using a "security by obscurity" mechanism. For example. here is a photo of mine (Heston Blumenthal's famous Bacon and Eggs Ice Cream for those playing along) which is supposedly only viewable by my friends. But because I managed to figure out the actual link to the photo (it's not very difficult for the average web user), I can now link to it for the whole world to see.


But who actually cares? In reality, everyone cares...as long as we're talking about things that happen in our "real lives". The most common example is that most of us like to keep our work and personal lives separate. We don't mix the two if we can help it. I have a few friends who actually sound completely different when I call them while they are at work. They sound "more professional" when they are working. And when they aren't, they revert back to the drunk fool I know from real life :-)


When it comes to the online world however, this changes somewhat. People seem to care less about separating their personas. It's partly a generational thing: I find people over a certain age (I purposely left the exact number out because this will be different depending on your perspective on things) who are fairly web-savvy try to keep things separate as best they can.

Of course, a quick search on Facebook will probably bring up your "private persona" but if you bothered to hide all the private info and your public profile picture isn't too incriminating, this doesn't matter. However, if I ask to be your friend, you may feel obliged to accept which then gives me full access to all your updates and the photos you forgot to protect with privacy settings. This scenario demonstrates how the current social networking model is broken because even if you want to present a different persona of yourself to me within Facebook, it's extremely difficult (impossible in some cases).


But when it comes to the younger crowd, very few care about splitting their online personas (even though they still bother with the mental separation of personal v.s. work in real life). They'll accept Facebook friend requests from anyone they've ever met which more or less gives everyone they've ever met full-access to their unfiltered ramblings and photos of them passed out on a friend's carpet while drunk.


The presentation struck a chord with me because the essence (at least from an identity standpoint) behind what we're trying to do with ProfileStamp is to be able to present a persona of yourself based on the viewer. If you've got an account and played around with the settings, you'll notice that you can be very fine-grained about the information shown when someone visits your profile. In fact, beyond simply hiding information when someone isn't allowed to see something, you can have a different version of the information shown. So, instead of having a simple yes/no decision to make, we actually cycle through the various versions of an attribute and show the relevant one based on the viewer. Of course, if there is no suitable version to show, they see nothing.

The mechanisms controlling the things your share about yourself online (data, photos, status updates etc.) need to move beyond the simple on/off switch model in place today. It looks like Google Circles plans to address this. I would assume Facebook is also looking at this given they have people like Paul Adams working for them.


The toughest challenge here is not the technology. It's not even usability (although this is more important than technology). It's actually user apathy. The average person (whether they are younger or older) doesn't understand privacy or access, let alone the controls one needs to work with to specify what other people can see. Most want the controls to be in place (or think they do), but they don't want to have to do any work to make it happen. That's something we've found with our set of private beta users. Most either leave the settings alone (which means their profiles don't present any information about them) or they ask for "a button that makes all my information public".

A secondary challenge is the lack of education about the damage that can be caused (to one's finances, credit rating, personal brand and so on) should the wrong things be made public. Our team had to actually advise a few of our users to restrict pieces of information to more select groups when they made them public. But until people start to realise this, they will remain apathetic and careless. Therein lies the challenge.

Scratching an itch

As is evidenced by my lack of blog posts and tweets, I've been busy. But I had some time off during the holidays. So what does one do? I built something just because I wanted it (yeah, I'm weird like that).

For quite some time now, I've wanted to be able to publish my contact details online but only have it exposed to the right people. But this has proven to be rather difficult (impossible, even). You either publish it, or you don't because you can't really tell who's viewing the information.

As an extension to this, I'm not a web designer by trade. If I want to have a web presence, I'm stuck with paying a web designer (which an average Jane/Joe is definitely not going to do unless they have a commercial reason or are obsessed with "personal branding") or using the many free templates out there. Unfortunately, free means "ugly" 99% of the time.

Finally, to actually get myself a web presence, I have to spend time filling in the relevant information and then work out how to host it somewhere or use one of the many online website building tools (many of which are free and will also host the site - but use the same ugly free templates available all over the web). Why can't I leverage the bits of information I have online instead of having to do more data entry? I don't mind sharing the info (as most services agree that "I own my data") as long as I have control over who can see it.

In short, here's what I wanted:

1. Identity-aware, access controlled sharing of my information.
2. An impressive, web-designer-quality profile page that would elicit a "wow, that's nice" response.
3. Minimal data entry.

That's it (for now).

Here's the result.

If you want to see what my new profile page looks like, here it is.

If you want your own profile page, please sign up for the free private beta here. In fact, even if you wouldn't normally want a profile page, you would be helping by participating. Feedback is all I'm really after right now so you'd be helping me out.

For those of you that want the geeky details about how it works, you'll have to wait for my follow up blog post :-)