That got me thinking – there really ought not to be a concept of federated provisioning.  Provisioning an application in the data center must be the same as provisioning an application in the cloud.  However, in the course of the conversation between James, Jackson, and Mark, it seemed SaaS applications and in-house applications were different from a provisioning perspective.

SaaS applications may be harder to provision and de-provision than non-SaaS application, but that doesn’t make them fundamentally different animals.  The point was made that SaaS apps lack a standards-based provisioning interface, an SPML interface.  The fact is the vast majority of applications, SaaS or not, lack a standards-based provisioning interface and this makes dealing with them very much the same.

Now there are two reasons that we don’t hear the same short of clamor about provisioning non-SaaS applications as we do with SaaS applications:

• We’ve dealt with it so long that pain isn’t as acute
• Provisioning vendors built an array of connectors, shifting the pain up a level, allowing companies to focus on the provisioning technology and not each and every application they want to provision

Provisioning vendors spent lots of time and money to build connectivity to traditional applications.  Lots.  And in doing so provided a bit of absolution for application vendors from their failing to provide a standards-based provisioning interface.  Having gone through all that pain and suffering, vendors are not eager to go through it again with SaaS applications, coding connectors to each one’s different web service.  Customers aren’t too keen on the idea either.

In providing SPML interfaces to their applications, SaaS vendors would do everyone a service.  Provisioning vendors could use their SPML connectors and not have to build to each SaaS application.  Customers wouldn’t have to write custom code to different service interfaces.

You don’t want that fired sales guy walking away with your customer list no more than you want him walking out the door with your pricing information.  To that end, there should be no reason why deprovsioning from an application like Salesforce.com is any harder than deprovisioning from LDAP.  Federated provisioning should not exist; there is only provisioning.

(Cross-posted from Burton Group’s Identityblog)

(Helps if I actually link correctly… doh!)

Identity consolidation says that I figure out how to get user stores out of my enterprise application and instead get these applications to bind at runtime to a directory service such as Active Directory.

Ah, so identity consolidation is centralized authorization.  Got it.

I am making the assumption here that when James says user store he means authorization store.  (Applications in this model still need some modicum of a user store if nothing else for auditing purposes.)  I am assuming the implication here is that after authentication comes a round of authorization that the directory service provides.  The application would consume this authorization data, at runtime, and act accordingly.  Theoretically, an enterprise policy (XACML) store could theoretically reproduce the authorization models of every application in the enterprise today and that policy tools would interact with this store.  Though I think this is a very viable model for customer applications (especially J2EE and .NET), I do not see it as an enterprise approach where complex applications like mainframe security and ERP roam free.

Identity management says that I should go create a strategy around provisioning of identity and leverage tools such as Sun’s IDM, Thor, etc where I still fundamentally allow enterprise applications to have their own user stores and takes me down the path of building lots of connectors… [snip]  I am of the belief that identity management (provisioning) propagates and encourages an otherwise bad architecture.

I look at user provisioning as dealing with the reality (and foreseeable future) of the enterprise landscape.  That landscape involves lots of user and authorization stores.  For reasons I discuss below, that is not going to change any time soon.  It is better to provide flexible, short time-to-value solutions, as identity management does, that address the reality of today than to wait for the ideal enterprise landscape to arrive at its glacial speed.

I disagree with James’ assertion that user provisioning requires the construction of connectors.  The connector wars of the provisioning world are over.  Connecting to systems like a complex bespoke application or RACF or SAP has become a science, not an art.  On the whole, provisioning doesn’t require connector construction; it requires configuration.  Each provisioning vendor worth their salt has a way of quickly connecting to “unknown” systems that don’t require core engineering efforts.

The one thing that I would also love insight into is how to get vendors who still insist on having their own user stores (e.g. Documentum, Alfresco, etc) to see the error of their ways and to take quick steps towards remedying them.

I think you’ll find the reason the vendors give on maintaining their own user and authorization stores is much the same reason why they have yet to adopt Service Provisioning Markup Language in a meaningful way.  There is nothing in it for them.  Nada.  The only vendors who might stand to gain (and thus adopt) centralized authorization are mega-vendors like IBM who have dozens upon dozens of applications.  For these vendors, producing a common auth store with the requisite halo of tooling becomes a path to customer lock-in.  “Ms. Customer, you can use AuthStore 5.0 to manage all of the authorizations for all of our products.  And here is AuthManage 6.0 to help you do just that.”  And if the customer ports their bespoke applications to the common auth store, the vendor gets big-time lock-in.  Want to get rid of XYZ Vendor?  You’ll have to reincorporate authorization stores into your applications. I have to imagine externalizing an auth store for a homegrown application would be painful, undoing that work even more so.

Stepping back to what I originally wrote about: no amount of centralized user and authorization management will make up for a lack of strong organizational and business process understanding coupled with appropriately defined controls.  That is the fuel for identity management and, frankly, identity consolidation as well.

They covered the usual tips for a successful deployment:

• Involve the business
• Planning makes all the difference
• Don’t bite off more than you can chew

Pretty standard stuff that always bear repeating.
There were some very interesting other observations:

• For complex systems, like ERP, get the vendor involved in the provisioning project
• Plan for testing early in the project
• Plan for sustaining the deployment, turning it from a project to a program early in the project

The idea of getting the complex system vendor involved in the provisioning project strikes me as both novel and extremely effective. The nuances of complex systems like ERP and mainframe security can bedevil a provisioning project.  Might as well go to the experts early.

Their last point on planning for sustaining the project echoes a point the Phil Becker and I made last year on identity management as a lifestyle and not a project.  You’re going to live with you decision for a lot longer than you probably expect.  You have to plan on how to sustain the deployment and turn it into a key thread in the fabric of business services the organization relies upon.

Deloitte speaking across all of their deployments, not just Sun’s, had some interesting observations as well:

• Half of all identity management deployments end up as shelf-ware (I think I hear Bill Malik chuckling somewhere)
• The true return on investment is not in the technology but in the re-engineering of process

A common misconception is that deploying a user provisioning product requires a massive process re-engineering effort.  That is not strictly true.  Mature provisioning products these days can accommodate most business processes, no matter how arcane.  That being said, deploying provisioning certainly encourages process re-engineering.  The deployment gives an organization an excuse to examine what it does and how it does.  “Do we really need five approvers just to give someone email and why do we have to fill these forms out to do so?”

So far, DIDW has not disappointed.

MaXware was known, primarily, as one of the three major meta/virtual directory companies out there. Maybe SAP saw wisdom in Oracle buying OctetString? (I’d be feeling pretty lonely right now if I was Radiant Logic.) Maybe SAP really just needed the connectivity that MaXware could provide?

I wonder what this means for corporate SAP partners who are already in the identity management space? If I am a provisioning vendor who has spent resources developing integration to SAP and the Virsa bits, I am going to be pretty annoyed that SAP just bought a provisioning technology. Integration partner one day, direct competitor another.

The real reason SAP made this move is the continuing SAP – Oracle War. SAP needs to be able to check the boxes off in an RFP that they have provisioning and identity management services. If SAP is looking to even the playing field, there’s at least one more acquisitions they have to do. They need to buy a large services company likes of Accenture or Booz Allen Hamilton. Granted, doing that will agitate their service partners, but that being said, it would round off SAP and enable them to go toe-to-toe with Oracle.

In closing, I wanted to include a few insightful thoughts from Jackson Shaw. I just discovered his blog… good stuff. Jackson writes:

SAP AG is acquiring MaxWare because they believe that if they can control identities, security and roles from within SAP NetWeaver then they can “own” an organization. They can be the tail that wags the dog.The few systems that SAP GRC can connect today stands out like a sore thumb. Who could take them seriously? Now, with MaxWare they’ll be able to connect to many more systems but will they be taken seriously?

If IBM can’t do it with WebSphere and Tivoli, I don’t see how SAP can do it with NetWeaver.