He ain't heavy, he's my clone

There’s a real tired old hack cliché stupid idiotic etc. movie plot that keeps getting copied over and over, and just about every time, it sucks. Two people standing someplace switch bodies. Hilarity is supposed to ensue, but usually doesn’t. Jodie Foster (yum) did Freaky Friday for Disney, and it was halfway decent. The remake with Jamie Lee Curtis (yum) was not. Sharon Gless and John Schuck did a TV show based on it in the 70’s. There were a few more. There’s a new one, the Change-Up, which appears to be the worst one yet. These closely resemble the other hack plot of old people being turned young for a time.

Can’t Hollywood come up with original stuff?

So now I’m utterly surprised that in this day and age, I’m still answering questions about “How do I clone the entitlements of one user to assign to another?”

WAH! Make Bob like Tom, we call that use case. And it’s a bad one.

One of my favorite true stories from the book is the insurance company in Ohio that let the old guys provision the new guys, because they knew where the bodies and the entitlements were buried. That’s not much of a foundation for provisioning policies.

Sure, it’s good to have a working model. You build a foundation for a set of entitlements, so that you have consistency, a set of policies that govern it, you already know who owns it and who assigns it and who approves the pieces. It’s called role-based provisioning. Then maybe add a few variations, perhaps even a couple of one-off entitlements. They’re called exceptions. Here’s your role, plus a couple of extras, all of it documented and duly governed.

But you don’t use another PERSON as your model. It’s like whenever I wipe my hands on my tee shirt, my kids all yell, “Bad daddy, bad daddy.” If you grab the entitlements of a current user and simply slap them on another user, you are a bad daddy.

Why? For several reasons.

First, you don’t know what else that model user has picked up over time. Sure, maybe he’s doing the new guy’s job right now, but maybe he’s bounced around over the years, and has some access rights you forgot about. Entitlement creep occurs when people keep old access after being granted new access. Nobody shut off that old stuff. It’s what attestation is all about. It’s also proper deprovisioning practice to make sure you only keep the stuff you’re supposed to keep, with all the old bread crumbs getting eaten up when you get transferred. You can’t look at receivables anymore because now you’re in payables, and it’s a conflict of interest, a segregation of duties violation. You can’t request payments and approve them as well. You can’t prepare the financials and be the one who signs off on them. Et cetera.

Second, what happens when the first guy goes away? Does that mean the second guy is now the model when you hire a third guy? Bad daddy.

Third, auditors will hate you. They will think you’re a nincompoop. “He got his stuff because this other guy had the stuff first? You moron.”

Fourth, users should get access rights for sound business reasons, and those rights should be governed in a sound business manner. “You were hired for this position, so we will grant you the proper role or roles for that position.”

Fifth, change management. Let’s say the virtual role changes. Do you go around to all the individuals who are doing that job and change their access? Bad daddy. Very inefficient. Better yet, with role management, you change the role, add or delete or change the entitlements contained in the role, and have your RBAC system automatically modify the access for all users who currently inhabit that role.

This is what tools like Oracle Identity Analytics (OIA) are for. Find those entitlements, create roles out of them, use those roles to feed provisioning, and by the way, occasionally attest to them to make sure people keep only what they’re meant to have in life.

Nobody should automatically be like somebody else.  I mean, sure, if everybody was like me, we’d all be better off. But I’m an exception.