Navigation
The Black Book of Identity Access Mgmt
This form does not yet contain any fields.

    Entries in provisioning workflow policy compliance oracle identity manager (1)

    Saturday
    Oct262013

    NO MORE MR. NICE POLICY

    I’ve stopped being patient with people while boarding planes. Recently, while stumbling onto a puddle-jumper to Columbus, the guy ahead of me stopped to get something out of his backpack, and seemingly fiddled with it for minutes. He finally put the thing in the overhead, before opening it up again and to dig some more. Then he pulled it back down OUT of the overhead to once again search. I finally said, “Pal, why don’t you do that out of the aisle, so everybody else can get by?” He gave me a nasty look, but screw it. “There’s a crowd back here,” I told him, and essentially shoved past him.

                   There’s a reason for rules, and for enforcement. It keeps everybody moving forward. If we allow anomalies to hold things up, none of us gets anywhere. This is why I’m a huge believer in AUTOMATION. If you have policies and procedures that must be satisfied, in order to keep things moving, in order to keep people in the box, in order to keep you and everybody around you out of trouble, then you should follow those policies, and even st up a little robot guy to guarantee compliance. In the identity governance world, that means workflow.

                   You create policies that say, “Once the warm body hits the HR system with a status of EMPLOYED, give the guy an email address, look up the other stuff he should get, and give it to him. Make sure that’s ALL he gets, but make sure he GETS it.” This means that warm body is enabled, with least privilege, so he’s productive, but not dangerous.

                   When something changes, like that warm body gets transferred, or terminated (thus becoming a cold body), your workflow should make sure those privileges change or just plain go away.

                   When you first put this stuff in place, you might arrange for workflow to simply NOTIFY, that is to send out emails to the people who must make stuff happen. “Hey you, give that guy an email address.” This way you can test out your logic, instead of finding out the hard way that your automation hasn’t been misconfigured to give a guy nineteen email addresses.

                   Then to make sure you’re keeping an accurate inventory of that guy’s stuff, you ask for feedback. “Hey, did you give that guy an email? Didja? Didja? Didja, huh?” And you keep bugging until you get that feedback.

                   And when you’ve gotten your logic sorted out, you complete the automation by installing CONNECTORS, sometimes called ADAPTERS, sometimes called MAGIC LITTLE GUYS THAT DO MORE STUFF.   If the email request is approved, then the workflow asks the connector to automatically create an email account. Then later the Unix account, the LDAP account, and so on.

                   I can’t believe the customers I run into who OWN these kinds of systems, and don’t use them. They might as well put in a help desk app for provisioning. That would reek, yes, but using your provisioning system for notifications only, forever, is like putting your kids in the car and then PUSHING the damn thing to soccer practice. Recently I advised a client with an identity product that competed with mine to USE the thing. All they do is notify. What’s the point? You’ve got an elephant gun, but you use it to hunt flies (not that I’m advocating shooting elephants, so spare me the angry emails).

                   Automation enforces your rules, keeps things accurate, keeps an audit trail, and saves you work. This isn’t like the collection of useless apps on your smart phone that you downloaded and used exactly once. This is good stuff, necessary stuff. Make it work FOR you.