SPML Under The Spotlight Again?
Mark Diodati of the Burton Group (that’s still how I should be referring to them, right?) wrote a post entitled “SPML Is On Life Support“. It is a great read, as it captures all the issues that have been plaguing SPML for years now. And the simple fact is that SPML simply has not lived up to the expectations that were placed on it, leading many like me to wonder if alternative approaches are going to emerge and eat its lunch.
But as Mark also points out, “…it (or something like it) is desperately needed“. Because access provisioning is still the most complicated engagement in any identity management project, and the biggest complexity currently comes from the need to develop, customize, deploy and maintain connectors to hundreds, even thousands of systems. The cloud amplifies the issues to emerge, since without standardization, an enterprise simply will not be able scale out to meet the management needs of their environment.
At Oracle, we have been talking about Service-Oriented Security for a while. The idea is simple – all the security functions, which includes identity management, need to take the form of discrete, easy to consume, standardized services that are part of the platform on which applications are built. This has always been an easy concept to understand when discussing certain service categories like authentication. But provisioning has been a tougher nut to crack.
Provisioning systems today add a vital business process layer to your identity management deployment, dealing as they do with the lifecycle management of identities and the orchestration of policies, rules and workflows around that. So even in a future where architectures will rely on the “pull” model (as Bob Blakley has been talking about), there will be a need for the more complex applications to interface with a provisioning service (different from the attribute service use case) to deal with lifecycle management issues around application access. This is where we believe the next iteration of SPML (however radically different it looks) needs to fit in. This idea is illustrated in the figure below.
This is one of the challenges we have been trying to solve as part of our Fusion architecture project. Do we have it solved? Well, we’ve started the journey at least. Asking applications to come around to a new architecture and way of thinking takes time. And we have to remember that there are still a lot of applications that will not be dropping their user tables and identity silos any time soon, so we have to be mindful of accommodating those applications as well.
Is SPML on life support? Not quite, judging from all the RFP requests that still ask for it to be supported. But it desperately needs some energy to be put behind it. And it needs to adapt to these new architectures, new use cases and the ecology of standards that is far out-pacing it. I believe Oracle (led by folks like Prateek Mishra) will be looking to take some leadership in the evolution of the standard. Let’s see if we can turn things around.
My experience so far with SPML has been good. Many of us in the industry waited around for the SPML v2 standard. It really was a V2 of the standard adding things like “modify” and “password” capabilities which actually made SPML useful. It's really unfortunate that many of the vendors haven’t adopted it. I dearly want to see SPML as the enabler of loosely-coupled identity architectures. Unfortunately, software vendors usually equate loosely-coupled with “easily replaceable” and the best way to prevent that is to either not support the standard or use custom capabilities that require a specific implementation like many people do according to the interviews i listened to found by http://www.mp3hunting.com SE.
My experience so far with SPML has been good. Many of us in the industry waited around for the SPML v2 standard. It really was a V2 of the standard adding things like “modify” and “password” capabilities which actually made SPML useful. It's really unfortunate that many of the vendors haven’t adopted it. I dearly want to see SPML as the enabler of loosely-coupled identity architectures. Unfortunately, software vendors usually equate loosely-coupled with “easily replaceable” and the best way to prevent that is to either not support the standard or use custom capabilities that require a specific implementation like many people do according to the interviews i listened to found by http://www.mp3hunting.com SE.