The best identity in the whole wide world

My dad fought in Burma during the Big War. He’d signed up when he was underage, right after Pearl Harbor, and ended up in the cavalry. There were, and still are, plenty of places where guys go in on animals, because of the terrain. During his service, he almost died of lockjaw after being shot in the foot (which had the unintended benefit of keeping him out of the awfulness in the Philippines), and then almost died more than once from crap he contracted while slogging through the jungles. At one point somebody assigned an author to follow his mortar squadron around Burma, and that guy was nice enough to write Dad up in his book (Marsmen of Burma).

Dad never talked about his service, until he was much older, and we started pulling stuff out of him. He never did veterans’ stuff, never told stories. That's how those guys were; they did what they were expected to, with a lot more humility than any of us are capable of. But my brother and I weaseled a bunch of stuff out of him on a trip to the Ozarks, and then another writer interviewed a ton of WW II vets and wrote yet another book, and my dad’s in that one too. So it was really surprising that he accepted an invitation to fly to DC with a bunch of other veterans in June 2010. It was a one-day affair, in and out, a hellishly long day for a bunch of guys in their 80’s and 90’s. But this he did. They were escorted to a variety of memorials in Washington, lots of pictures were taken, they got fed lunch, and they got delayed for three hours coming home because of weather.

Once back in Chicago, the reception was huge. Fire engines shot water cannons over their plane, and thousands of people were there to greet them, with music and flags and cheering. And this was the first time he’d ever done one of these.

My old man was born in 1924, the second oldest of ten kids. He left high school during sophomore year to help support the family. After the war, he married a most excellent chick, and together they raised five excellent kids. He was a fireman, he helped build the Mackinac Bridge, then he started multiple successful businesses, retired, got bored, took a night job, and six months later they put him in charge THERE, and he remained another nine years.

Everything I know about dealing with difficult people, and handling myself with respect, I learned from him. None of us ever got a job, bought a car, rented an apartment, sold a car, bought or sold a house, or did much of anything, without checking with him, because he would tell us all the angles. “Did you think of THIS?” If we ever got away with anything, it's only because he let us. He’s a human lie detector, and generous to a fault. If I have anything resembling decency and strength in me, it’s because of him and his most excellent chick

What’s this got to do with identity and access management? Not a damn thing.



Sorry, but you're just too ugly to access the system

Multi-factor authorization good, hackers bad

I’ve taken da wife and kids all over the country, and even out of the country. We’ve been to large metro areas, tiny little towns full of the antique stores that she loves, the mountains, the oceans white with foam, the Gulf (before it was black with oil), the islands. We’ve also gotten to see a lot of wildlife in the, uh, wild. But the one animal I’ve never been able to show her in the wild is a moose. I’ve been hearing about the frigging moose for twenty years. Never seen a moose in the wild. Last time at Brookfield Zoo in Chicago, the moose there was hiding. “Moose don’t like you,” I’ve tried to explain to her.

And so I kept this i mind, when I went online to our bank’s website, to create an online account, and I was asked to pick an anti-phishing image for authentication. You can pick various backgrounds. This way, if I ever get an email saying, “You need to check your account online,” and I click a link to go there, and I don’t see my personalized image, I know I’ve been phished, and I need to make like the good shepherd and get the flock out of there.

For my personalized image, I was a total smartass, and I chose … a moose. The system chose FOR me a personalized message, something regarding yet another kind of animal.

This system, as it turns out, is based on a product called Bharosa, which does multi-factor authentication, fraud detection and prevention, and multi-factor authorization. Bharosa was bought a while back by Oracle, and it is now called the Oracle Adaptive Access Manager, or OAAM. Oracle loves cooking up insanely stupid acronyms for its products. I mean, you think that one’s bad, how about the Oracle Applications Access Governor (OAACG)?

Anyway, it’s a pretty decent product, OAAM, and so when my bank was bought by another bank, and then THAT bank was bought by yet ANOTHER bank, they kept the thing in place. We pop over to MegaBank.COM, then up pops the moose and phrase, we stick in a user name, then on the next page we get asked for a password, and bing, we’re in.

Actually, I wish I could have picked my own phrase, because then I could have “moose and squirrel” come up, which is barely funny, and even then, only if you’re old enough to get the joke.

You might say, “Gee, that sounds like a pain. Username on one page, password on another. What gives?” Well, it’s actually not a bad deal. If they don’t find a legit username from the first page, they never forward you to the second page. A setup like this could also mitigate some of the danger of SQL injection, if you’re not already coping with that via input validation (which you should, you lazy ape).

OAAM also supports virtual authentication devices, which don’t require client software, and which prevent man in the middle, over the shoulder, under the elbow, and through the Adam’s apple attacks. If your virtual authentication device comes up more than once, it will play back with the keys moved around, to avoid anybody recording your keystroke coordinates. It can even let you register particular physical devices, such as PC or smart phone, and disallow a device that’s not registered. On top of that, it can match up time of day, historical behavior, transaction context, IP address or even country of origin, shoe size, you name it, in order to calculate risk score and decide whether or not to block a transaction.

“You say you’re the CEO? Okay, but you’re logging in from where? Russia? Screw you.”

“You say you’re the CEO, but you’re logging in from outside the firewall, on a Saturday night, and you wanna check out salary info? Screw you.”

“You say you’re the CEO, but you’re trying to download a thousand engineering specs all at once? Screw you.”

“You say you’re the CEO, but you’re trying to access HR data from a Blackberry? Screw you.”

“You say you’re the CEO, but you’re trying to perform a wire transfer in excess of $50K, and you’ve never done anything like that before? Tell you what, I’ll send you a one-time use pin to your cel phone. Gimme that right back, and you’re good to go. Otherwise, screw you.”

“You say you’re the CEO, but you logged in from Minneapolis, and ten minutes later tried to do something else from Florida? How fast is your car, really? Screw you.”

And so on.

Hackers are smart, and always getting smarter. Check out the massive TJ Maxx attack. It wasn’t a single attack, even tough some of the lazier newsguys recorded it as merely a SQL injection hack. It was a whole series of hacks, allowing the bad guys to create a beachhead and branch out. They pulled data out of there nineteen different ways. SO you need to look at who they say they are, what they’re trying to do, what they’re using to try it, where they’re trying it from, when they’re trying it, and how much of it they’re trying. Any one of those things might be okay, but taken as a whole they might tell you a different story.

Night of the Living IAM Solution

In which your identity product becomes The Undead

In the last seventeen years, I’ve been at two companies that acquired smaller companies, inheriting technologies that in no reasonable fashion integrated with their existing product line. Both employers practically bent over backwards trying to rationalize why they bought these smaller companies whose products made no sense at all in the acquiring companies’ stacks. In the first instance, both companies shared board members, and the bigger, profitable company was used for bailing out the smaller, failing company. The larger org’s stock understandably took a hit, leading to shareholder lawsuits.

In the second instance, the guys at the top honestly thought it made sense to acquire another company whose product was absolute crap and didn’t fit their strategic direction.

Cisco buys technology that they hope to put on their hardware. They paid $100 million for Securent, then a couple of years later have practically sh_tcanned it and replaced it with Rohati. Rational used to buy things that they actually used, but which simply turned into menu options in the existing product line.

In the case of Oracle acquiring Sun, it actually made perfect sense. Larry gets Java, and bunch of hardware, and of course a whole lot of customers. In some ways, it might have made more sense for IBM for them to get it, given the fact that they obviously know how to sell hardware. But Oracle has had a software/hardware mojo going with Sun by way of Exadata. And the folks at Oracle, unlike some of the folks at Sun, like to make money with the stuff they make.

What sort of got lost in the haze was the fact that both Oracle and Sun had large installed bases of their respective identity and access products. This was not part of the strategy; in the case of Oracle, especially, the identity sector is a fraction of the overall business, although projected to grow significantly. The Sun identity practice came over with the rest of the baggage, and represented an obvious overlap. Sun Identity Manager was a decent product, no doubt. It has a significant base. But now it’s going to be the also-ran, while Oracle Identity Manager is the strategic product going forward.

So now comes the inevitable question, what happens to all those Sun customers?

First off, my big, hairy disclaimer: I have been making a good living for a couple of years flogging the (IMHO) excellent Oracle identity stack.

Oracle supports acquired products indefinitely, which is a good deal if you’re one of those customers, but of course it’s expensive. So nobody has a gun to their head to migrate. Of course, how much development do you put into a product that’s effectively deadended?

Because I’m a morbid kinda guy, I refer to Sun Identity Manager as a vampire child. It’s been bitten in the neck, and therefore while it will never lose anything, neither will it get any older. What it is now is what it will be until 2017, when support is scheduled to end.

Any time you’re talking about migrating from any kind of enterprise solution, it’s not simple. Sometimes these efforts can be at least semi-automated. There are tools that will turn Siteminder policies into Oracle Access Manager policies, for example. But there are no simple ways to migrate provisioning workflows, by contrast, from one solution to another. It’s not just the scripting language, it’s also the architecture, the connectors, the adapters, you name it.

You could say that, if it’s a difficult migration where a lot of the work is manual, meaning less migration than fat fingers, what’s the difference if you go to one solution over another? You’ve got to retype a whole bunch of crap no matter what. So here’s what to consider:

• Microsoft has a repackaging of old stuff and OEM stuff in a dubious smorgasbord with currently limited functionality.
• Novell’s near term future is spooky, given their on-again off-again acquisition status and the many rumors that, if they get bought, they’ll be carved up.
• CA, IBM, and Oracle are all out there with large customer bases and lots of resources.

Let’s boil provisioning down to a couple of components, workflow and connectors. The former walks you through the steps, the latter makes stuff happen at each step. Until the whole world’s talking SPML, everybody’s connectors are proprietary. The workflow, including design interface, encapsulation, delegated admin, and other nuances are where the real value lies. If you decide to POC the effort, consider a handful of use cases, such as “create a user,” followed by “modify, provision, re-provision, de-provision, transfer, and terminate.” In the case of a SIM customer, you might think that Oracle has the leg up, since they now own the folks who have the best understanding of where you’re starting. But again, that’s why Ja invented POC’s.

The best thing about being in this situation is, you’ve got plenty of time. Support for SIM until 2017? In software, that’s an eternity. Of course, you’re running on the Vampire Child product. And also remember this: all those mainframe dummies who were content with a six-digit date format were scrambling when Y2K came along. You've got a lot of time, and at the same time, less time than you think.

I've got standards coming out my wazoo

There’s an old joke on a parody of medical shows in which a young woman lies in a hospital bed, hooked up to tons of tubes and wires, and when the nurse asks what’s wrong with her, the doctor replies, “She has a complicated disease developed by specialists.”

Nothing gets experts more giddy than creating terms that get wrapped up in acronyms. At conferences, in meetings, on blogs, they will build and enhance guidelines and standards that they can put their names to, publish papers about, and practically wet themselves with glee if they get used in product development.

Not to say that all these standards are worthless, although an awful lot of them end up gathering virtual dust on the virtual shelf. Some of them are even great ideas, but they just don’t catch on, for whatever reason, and this includes within the IAM realm.

In the higher education arena, we have more than our share of these. Services Provisioning Markup Language (SPML) gets tossed around a lot. It’s actually a great notion. It’s Esperanto for making provisioning calls between requesters and target systems that don’t otherwise speak the same tongue. Some of the smaller “provisioning” companies fall back on it all the time. “Hey, you don’t need that big provisioning package, just use us, we skip the expensive connectors in favor of SPML.”

The problem there is, not too damn many packaged apps support SPML. So they end up falling back on flat files or, as with help desk apps, e-mail integration.

CARML (Client Attribute Request Markup Language) defines attributes and privacy requisites for an app. AAPML (Attribute Authority Policy Markup Language) defines which data elements, usually relevant to IdM, are available to applications, and how these elements can be used. Which fields in my own profile am I allowed to edit?

When you already have it figured out between parties what data to use and how to use it, you’re all set. But we’re moving slowly toward an environment in which we all talk standards instead of contractually-defined protocols, you can use these kinds of standards to specify what data you will make available, and the rules for using it.

The higher education space just loves creating standards. Hardly anybody seems to use them, but they’re there. Ever heard of eduPerson? eduClass? Shibboleth? They’re in use, but not in the volume you’d expect, considering how much they get talked about.

DSML is for using HTTP to talk to LDAP. It’s a cool idea that hasn’t caught on much.

Which ones seem to be the most relevant? How about XACML (Extensible Access Control Markup Language)? It describes who can access which resources. It can introduce a user to a system, as well as store policies. I know a guy who actually contributed to that standard, and it’s a nice thing to have on the resume. A million years ago I contributed to a conversation about a standard that eventually turned into another standard that’s HEAVILY in use, but my contribution was so ridiculously minute that I don’t even really bring it up much. It’s like saying, “See that skyscraper over there? I buffed the floor in the lobby before they let the first tenant in.”

Which brings me to … SAML. I won’t even tell you what it stands for, because you should know already, you boob. But without it, we’d be stuck with some less wonderful standards for federation. Everybody in the space knows about SAML. See, sometimes these things actually take off.

Years ago I came up with some of my own:

• ENAML: federation for dentists
• SPAML: to tell your email server which stuff goes directly to Trash
• FLIM-FLAML: order before midnight tonight
• EGGS_N_HAML: for ordering your breakfast over the Cloud

Standards are good things, but only in small numbers. They take forever to get adopted, and you sure don’t want to be the first one on your block to dedicate engineering resources to supporting one. Remember S-HTTP (not to be confused with HTTPS)? Yeah, I thought not. The way to avoid a further glut of acronyms in this goofy business is to set the bar higher. When I stage my benign fascist takeover, the first thing I will do, after the flogging of the lawyers, and the cloning of Heather Locklear, is to establish a law stating that, before you can launch a new acronym, you must be able to recite all the other acronyms, explain what they mean, name at least one vendor supporting each one, explain why yours is worth a s___, and then get hit in the head with a stick.

What’s great about a cheap IAM solution? Well, it’s cheap, anyway

Over a dozen years ago, I worked with a set of testing tools from a particular company. One tool performed regression testing, and the other performed load testing. They competed with Mercury Interactive, which itself had one of the more interesting reputations in the market. Anyway, one day this testing company had the brilliant idea of creating a tiny bit of integration between the two tools (using the scripts generated from regression to feed load tests), package them up, and give the same old tools a new name. Instead of testing tools, they were now a SUITE. It actually wasn’t too bad an idea. They had a good thing going for a while, until bad management and some very questionable practices led to the defection of half the work force and a delisting from NASDAQ.

I’ll keep any comments about questionable Microsoft practices aside and simply observe that they have pretty much done the same thing in the identity space. They’ve taken MIIS, which wasn’t exactly setting the world on fire, glued it to Sharepoint and Active Directory, thrown in their big Euro partner and a few other pieces, and re-christened the whole mess “Forefront.”

I’ve seen (just a couple of) companies build their own provisioning, if you could call it that, with Sharepoint alone. GAH! The workflow is brutal and rigid, an all or nothing proposition that you don’t want to fool with once you’ve put it together. These deployments typically have multiple workflow definitions per location or business unit, with no reusable pieces. It’s also terribly fragile.

Sharepoint is a weak point in and of itself, with its all or nothing security model that is often poorly configured and, of course, dependent on AD groups. Check out one of my earliest posts for the lowdown on MOSS security.

With the other OEM pieces in Forefront, workflow is a better proposition than just plain Sharepoint. You can use Omada’s visual workflow, OR you can build it in Visual Studio. Icky poo poo. However, extending it typically means coding. There are no real ERP connectors, nor is there a Unix connector. Notice my erudition, as evidenced by my use of the word “nor.”

Attestation is attribute-only (unless you use Omada). This is a legacy thing they’ve never fixed, physically or philosophically. It’s based on the old paradigm where provisioning in Windows meant filling in AD attributes, which the applications would have to come query to see if a user was allowed entry. It’s incredibly arrogant on their part.

Another legacy thing: the use of Crystal Reports. Gah! That thing will not die. Where’s the analytics? And SSO is severely limited, and as usual, it includes Kerberos, or at least Microsoft’s version of it.

So let’s look at the business angle. I mentioned yesterday how Novell used to compete with Netscape LDAP by offering a lesser but CHEAPER product. In fact, it often went for ten percent of Netscape’s price, and usually came with ten percent of its functionality. So what Microsoft is doing with Forefront is making the thing very, very, very price competitive. It doesn’t do what the others do, and extending it takes a lot of work, but it’s cheaper or, in some cases I’ve found, free to existing MS customers. WOW, you say, if it’s that cheap, I can afford the consulting help to build it out, right? Well, Skippy, hang on. What you also need to look at, besides TCO (total cost of ownership) in the short term (what it takes to build out), is the long term cost. Can you migrate it to something else if need be? How much will it cost you down the road when you want to make the simplest changes? Will every change requirement mean coding yourself out of a corner?

 “Free” sounds terribly intriguing. But if it sounds too good to be true, then it’s too good to be true. Before going whole hog with Forefront, I’d highly recommend a reasonable proof of concept, and make sure you watch how it’s done. Exactly what does it take to build out those use cases? How much customization is required? How flexible is it once it’s built? How many OEM parts are there? Then multiply that by the number of roles or groups or business units. Do the calculations. My wife the math teacher boils everything down to numbers. Y’know, as in “how many days has this been in the refrigerator?”