A Clear Business Case for Compliant Provisioning

I have spent a fair amount of time recently, ruminating on compliant provisioning and what comes after it. It is a fascinating mental exercise and if it remained as such, it would be useless. Yesterday, I got to see it in action. I was at a customer, watching our integration with their provisioning system get installed and configured. It was, as all good software installs should be, quite boring. But what did captivate me was the business case and drivers for compliant provisioning. Though our customer has a mature provisioning system in production, they have yet to achieve fully automated provisioning. Why? Certainly not for lack of trying. Because their SAP environment is large, complex, and ever-changing, they cannot implement a comprehensive set of automated provisioning rules for fear of SoD creeping in. They already rely of Approva BizRights to do “What If” analysis. It verifies on an ongoing basis that role definitions do not generate separation of duty problem as well as make sure accounts don’t contain any SoD problems as well. Currently, their outsourced help desk fields access requests. They gather up the roles being requests and use BizRights to perform What If analysis on the proposed account changes and then route the request on for provisioning. Instead of an access request flowing to the help desk then into BizRights for analysis, they plan on automating the access request via their provisioning system. By using our “What If” analysis within the provisioning system they can cut out the help desk all together, eliminating that manual step. A handful of their SAP systems generate the vast majority of their ticket call volume. By implementing compliant provisioning, integrating BizRights with their provisioning tool, they are looking to cut that call volume down to 0 and save a bundle in the process. A couple more of these kinds of deployments and compliant provisioning will be the norm in the provisioning market… and then I’ll be talking to you about what comes next.

You mean people actually use this stuff?

Matt Kelly at Compliance Week threw out a line recently:

Compliance Week is researching a story about compliance with identity management and user access policies. We’d like to hear about what policies you have in place for those needs, and what problems you’ve encountered (and solved) along the way. Send us your thoughts, and expect an article on the topic in upcoming weeks.

Needless to say, I am very curious what people will share on this subject. I’m always fascinated to hear how people apply user provisioning tools. Back in the day there were two major selling points for user provisioning: compliance and reduced help desk call volume. Customers were quick(er) to recognize the reduced help desk call volume but the compliance aspect lagged, mostly dueto the fact that no one knew what compliance meant. (These were the pre-SOX days mind you.) Times have certainly changed as has the messaging. Recently provisioning for compliance has morphed into compliant provisioning. User provisioning systems have matured to a point that organizations can use them as service platforms. Organizations are realizing that their provisioning infrastructures are great vehicles for other services: password management, role lifecycle management, and so on. Compliant provisioning is one of the best examples of this. If our recent webinar with KPMG and IBM was any indication, then the market is desperate for compliant provisioning solutions. We had hundreds of attendees asking some very tough questions about implementation, architecture, and resources needed. I can’t wait to see if Matt’s research reaffirms what we are seeing in the ever maturing provisioning market.

No identifiers, just attributes, uniqueness: Where's the context?

So Mike Neuenschwander hung a softball out there with his latest post on becoming an OpenID power user. Dave Kearns was quick to take a swing at it with his response to Mike’s summarization: “There are no identifiers, only attributes.” Mike’s journey to OpenID begins with a single step - getting an OpenID, which is really an exercise in picking a name. Names are important. (I am going to stop myself from going into a discussion of the gravity of names and naming. Literature is soaked in naming issues.) As Mike points out he can pick any unused name (really, any set of unused characters.) The first person in to register ian.glazer.myopenid.com can purport to being Ian Glazer. This is no different than XRI name registration or domain registration or copyright registration… you get the idea. Dave goes from there and reminds us that identifiers have to be unique within a given namespace. He uses the example of disambiguating family members. He provides one of the most familiar examples on unique identifiers:

Fun thing to do on a snowy day

My friend, Nicole lectures up at American University. A few months ago I spoke to her graduate students on identity management issues. Today I did spoke with her juniors about reputation and identity. It is a funny thing what comes out of your mouth when you don’t have slides, have fifteen minutes to talk, and a very vast topic. My ramblings included:

  • an exploration of my wallet seeing what bits of identity I could find in there
  • a short talk on the REAL ID Act and some of its problems
  • which then lead to Jim Harper
  • I changed gears and talked about OpenID

Good fun on a snowy day. Nicole has an amazing network of friends. Last week, Tom Kyte spoke to her class. He brought a camera to class and took pictures. I told the class since I didn’t have my camera with me I’d just blatantly link to Tom’s shots. Thanks Tom! Tom’s picture of Nicole’s class While I’m on the subject of photos, Nicole is a photographer as well. I love this shot… and you can find more of her pictures on her SmugMug gallery.

SPML Decision Followup... followup

Conor has graciously explained the “strangeness” I felt in the Advanced Client scenarios. He explains that this part of advanced client work:

addresses the problems involved in provisioning functionality to a secure container that is associated with a user somewhere nearby

That snippet was enough for me to grasp it. Read the rest of what he has to say for more. I wanted to clarify on two points he made. First:

What I meant to ask was...

While the SPML in the Draft Liberty ID-WSF Advanced Client Specifications discussion continues, I want to go back to what I really meant to ask in my previous post. (I have a tendency to jump ahead a few questions, skipping over what should have been asked first, and asking deeper knottier questions. Attribute this to my habit of jumping into the middle of river before figuring out how to cross it… once you are in the middle of the river, you tend to figure it out very quickly.) Back to the question - what, if any, is the bridge between user-centric identity and “enterprise” identity? I can see somewhat of a bridge for companies selling federation. Andre has done a good job of explaining his consumer-centric authentication solution. I can see how Ping “backed into” this solution. From the enterprise’s perspective, can user-centric identity be seen a ultra-federation? Certainly, the tooling needed to handle a federation of dozens of partners is very different from the tooling needed to handle internet-scale federation. Perhaps the only true linkage is on the Relying Party side of things. “Enterprise” identity systems manage the back-end work; user-centric tools handle the conversation between user, RP, and IDP. I’m in the middle of the river here figuring a way to the other shore; help me out if you can.

Different... how so?

Thanks to Raj, Paul, and Conor for all chiming in on my previous post of SPML in the CardSpace world. Conor wrote:

However, we also decided that this “model of provisioning looked a bit strange” to try to shoehorn into SPML as the problem we were solving was just different. There was at least one contributor to SPML in the room while this disucssion was going on and the decision was being made, so I presume they also felt that the model was “strange” for SPML.

Is SPML irrelevant in the coming CardSpace/Higgins/OpenID identity world?

I was reading about Conor Cahill’s workshop at RSA on secure provisioning of network credentials over the wire. It was a joint proof of concept between Intel, BT, and HP using Liberty’s ID-WSF Advanced Client. They talked about how to get credentials from service providers down into a client environment. (Although it is not a requirement, clearly Intel would love it if the client environment was a TPM-like object.) One aspect of all this is a provisioning service, one for which Liberty has cooked up a spec. As a user provisioning guy this model of provisioning looked a bit strange to me. Think telephone service provisioning, not enterprise user account provisioning. The funny thing is, I thought there already was a perfectly good provisioning service standard out there - Service Provisioning Markup Language (SPML). That got me thinking. Provisioning is an aspect of the identity lifecycle that you don’t really hear about in talks on Higgins and CardSpace and such. This is a bit of history repeating itself. Back in the day, the authentication guys got all the glory, all the publicity, and when it came time to make sure there were actually credentials in back-end services, they waved their hands. It was the lowly user provisioning system, the late-shift janitor of the identity world, that actually had to do the dirty work. Who is this janitor in the user-centric identity world? Before I go on without a better understanding, I’m looking for comments on this one. Where does SPML fit in this brace new identity world? Is the intention that SPML will be passed as part of a larger SAML assertion to establish credentials? Is the PSTC working on scenarios like this?

Convenience over Security: The role of industry

New York is the location of yet another identity information on public website fun. It is sad, but I am kind of used to reading about these. What is slightly more shocking was the reason given why the data was out there in the first place:

The documents were posted on the New York site as a convenience to lenders looking to learn more about the financial status of potential borrowers.