Is anybody out there?

I belong to a fraternal organization. One of the big benefits is really excellent life insurance rates for members. But much like the drummers in Spinal Tap, every so often my agent explodes. I've had a few. One of the last ones made himself very unwelcome in my house when I failed a blood test because it said I was a smoker. The problem was, I had worked a five-hour bingo the day before. Prior to the indoor smoking ban laws in Illinois, bingo used to equate to old ladies with Marlboros. The blood test indicated I was a heavy smoker. Just so you know, that secondhand smoke thing is no joke. The result was a more expensive new policy. The agent told my wife, "He should sign the contract anyway, it's still a good rate, even for a smoker." That was the end of him.

Even more recently, I got checked out for a change in my policy. Flying colors. But my agent became less and less responsive. Eventually, he stopped answering emails. I floated a phone call. I finally went on their web site and found another agent, who informed me, "Yeah, Floyd has been gone for a few weeks now."

Meantime, my emails were going into a black hole, along with those of several other guys who'd also been trying to reach him.

This is yet another great example of bad deprovisioning policies. When somebody leaves your organization, you have, as I see it, four options with their emails. First, you route them to somebody else who will pick up the pieces. That's a very good approach. It keeps you from losing business.

Second, you kill the account and let those mails bounce. At least the sender knows it's a dead end, but this assumes they'll try to find another body to go to. It can look sloppy. But hey, it's better than thinking you're being ignored.

Third, put the equivalent of a vacation message on the email. "Sorry, this individual is no longer with the firm. Please contact one of these other guys. Here's their contact info." Give the sender multiple options, so it looks less lazy on your part. If you only give them one alternate contact, they'll wonder why you didn't just route them to that person in the first place. Put the onus back on them.

Fourth, leave the account active, and don't do anything with it at all. That's what happened to me. The account becomes a black hole, and results in very frustrated customers.

HOW you handle this situation should be a part of your deprovisioning practices. It should be in your POLICIES. I love that word, policy. In the IAM world, it's not just the way you've decided your org will handle a given situation, it's also hopefully how you've coded or configured your framework, so that it automatically kills, routes, captures. Sure, if you reroute a terminated user's emails, you have to assign a resource to monitor those mails. And you should. It's preferable to an interruption of service.

Your organization is only as strong as the weakest link. Keep all your links strong, even when in fact they're not there anymore.

Bumping up against the cloud

One thing I really, really, really hate about Windows 7 and the latest Office suite (other than the fact that these idiots have once again moved everything around for NO GOOD FREAKING REASON WHATSOEVER, requiring us to find old options in new places) is the need to be mouse-bound. I have an old colleague who amazed all of us by his ability to navigate Windows, including Explorer and all the other functions, strictly by keyboard. Lightning fast, in fact. He complains now that without a mouse, which is far slower, you can't get around.

Even without having taken a class on interface design, and creating Windows screens using C and Owl, I intuitively started building screens that could be easily operated with hot keys and shortcuts. But it seems nobody does that anymore.

Eventually, there won't be any more mice. It'll all be touch screens and voice activated. On a recent episode of 30 Rock, Alec Baldwin stands in front of a voice-ac TV and mutters the word "crap," which instantly brings up the Kardashians.

So what's the future hold for IAM? Like everythign else we do, it's heading for the cloud. But not instantaneously.  And the foot dragging isn't for technical reasons, primarily.

We still hear of having to mitigate multiple sources of authority, which sounds like an oxymoron, except when you consider this: we don't trust each other. I'm the source of authority for the CRM system, you're the source of authority for the forecasting system, and so on. In fact, fine-grained entitlements thrive on the notion that multiple authorities must be consulted.

I recently read a whitepaper which was trying to sell a particular vendor's cloud service for IAM, and it said that integrating new apps into an SSO structure was tough because for web SSO, you need to run agents on each app server. I'm not sure I buy that one, and regardless of how you do it, even if you're completely SAML-based, you still need to run something on every participating server just to eat and spit out SAML. So there's a weak argument.

You're always going to have limitations to SSO. In fact, as I've written in this space previously, we hear more and more about Reduced Single Signon, or RSO, in place of SSO. Regardless, with anything that’s got an “SO” tacked on the end of it, you have the additional complexity of multiple identities. I’m jeff.scheidel here, I’m jscheidel over there, I’m jeff1234 in the other place. My SSO/RSO function needs to look up the right identity for the right job, or at the very least provide to my target app whatever creds it needs to let me in. Oracle uses recently-acquired Passlogix for this. Other people use Symplified, Citrix OpenCloud, and then I’m writing something in Assembler on the side. Y’know, just for kicks.

There’s also still the need for connectors, or tunnels, or whatever terminology the vendors use, in order to jam creds into those individual apps.

But there’s always going to be that big limitation to IAM in the cloud: you’re not going to want anybody to provision for you. You will always want to control who represents you. Self-registration still needs approvals. In fact, it needs EXTRA approval.

When I was younger, I wanted to be a pro boxer. I was only able to get just so far. That’s just the way it is. Well, IAM in the cloud is only going to get so far, at least given the current environment.



Don't lose sight of the plan

Didja see the Packers beat the Steelers? I'm from Chicago, so I had mixed feelings. But my gut feel was that the Pack making it there and winning it all was at least rubbing it in the face of Mr. Dirty Text-boy Favre.

What I thought was a terrible start, however, was the National Anthem. Christina Aguilera mucked up the words something fierce. It's kind of hard todo, considering there aren't that many lyrics. Maybe if she hadn't spent so much effort SINGING SCALES instead of SINGING THE SONG, she would have hit the target. And then the halftime show was brtually bad. There was so much production involved, they forgot the MUSIC. It's just like the infamous Janet Jackson halftime show. Even if you subtract the errant body part, it was still on its way to being known as the dumbest, lamest, sleaziest show ever, and not exactly a glowing recommendation for parents to get their kids into football.

Okay, okay, what's this got to do with IAM? Actually, it's relevant to any major project. If you forget the actual objective because you go down ratholes, you will NOT succeed. At my last cube job ever, we worked for literally months to convert from a mainframe system to a more nimble system. Months. Then on the projected cutover weekend, management decided to put us off another week and sneak in a bunch of other functionality. THEN they decided to also put off a physical inventory and hold that the same week as the cutover. UTTER DISASTER. It could not have gone worse.

I've also seen this happen during IAM projects. "We were starting with basic auth and SSO, but now one of the stakeholders wants to accelerate SAP integration. So we're tossing that into Phase One." Integrations are often a mess to begin with, so they should be taken as their own mini-phases.

I've always said that in any IAM project, authentication, SSO, and the most basic authorization should come first. They are the foundation for eveyrthing else you might do. SSO leads the way for integration with various packages, and it's also the platform for federation. Start with the end in mind, sure, but don't rush that start TO the end until you're ready.

Who does IAM truly benefit?

Let’s be honest, the Human Resources department at your organization is not there to help you. Sure, they’ll get you a replacement medical card when you put yours through the wash, and they’ll help you locate local doctors in your plan, and tell you how to take a loan against your 401K. But that’s just frosting. What they’re really there to do is protect the corporation and management from lawsuits. That’s the bottom line.

Why do you need to know things like that? Well, here’s why. The way I approach everything and everybody that I interact with is, they’re all a black box. If I know how the black box works, then I know what I need to put into it to get the desired result OUT of it. An old boss of mine was motivated by avoiding scrutiny and never wanting to lift a finger if it didn’t involve retrieving donuts. If I ever needed anything, all I had to do was outline to him what I needed, then my intended path to getting it, and if my plan involved talking to anyone above him in the org chart, he would suddenly get animated and take care of it for me. The rest of the time he simply stayed out of my way. Understanding his motivations helped me achieve my goals. Black box.

An identity and access framework is the same thing. Sure, there are benefits such as SSO, or at least RSO. And it should guide you to the desired landing page and appropriate links based on your role. It should give you that access in a timely manner, once approved.

But really, IAM is there to benefit the organization. Your SSO is the organization’s faster path to your productivity, which makes you feel better about yourself, but it really all about them. The same goes for your automated provisioning. And password reset. Even more of a bang for the org is the stuff you DON’T get, such as access to stuff you shouldn’t. The audit of everything you do, including the requests that are denied. Oh, and don’t forget the automated DE-provisioning. It’s the organization’s security.

It’s like the company Christmas party. It costs the boss a few bucks for booze and finger food, but what do you really get out of it? Now imagine you’re the security chief. Understand the motivations of the organization, and pitch to them what you need in terms of AAA. Black box.

IAM protects your data and IS your data

When you first slap together an IAM framework, it’ll be perfect. For about a week. Then you’ll start saying, ah crap, I forgot this, and that, and the other thing. It’s kind of like life, marriage, painting the garage. This is why you have policies that can be changed centrally, this is why you have software (eg. OAAM) that can learn from activity and help you fine tune, this is why you have audit trails to tell you what you missed so you can plug the next set of holes.

So let’s consider these for a moment. That same IAM toolset that’s making sure the people who log in are exactly who they say they are (reminds me of a rant by the Arizona Cardinals coach from a few years back), and which gives them access to ONLY those things they’re allowed by virtue of their roles, attributes, or shoe size, is also GATHERING information as it does all this. Who asked for what, who got what, who was refused what, and so on.

The data that tells you who normally gets things on a granular basis is the same data that helps you build roles. If you and I and that hairy guy over there all do approximately the same thing for a living, and we use approximately the same resources, then we might just share a virtual role giving us access to those resources. But if I start doing things a little differently, such as doing more of my job from the road (as evidenced by the IP address(es) I come in from, or I start doing more work outside of normal business hours, then either my role, or the policies that govern my role, or the exceptions to the role, may need to change.

This is why your IAM framework must do an excellent job of auditing. It’s not just for forensics or security recaps. It’s also for fine tuning. If you CANNOT run a regular report that tells you who asked for, received, was refused resources, then you’re missing half the value you should be getting, and you need to fire the guy who bought the access product and beat your vendor with sticks.

If your framework, on the other hand, protects your innards without telling you simultaneously how to do it better, then it’s like what Homer Simpson says about beer: it’s the cause of, and the solution to, all our problems. Make sure your framework is all solution, and no cause.