Category Archives: SPML

Pulling LDAP

Posted on February 24, 2010 | 6 Comments

Mark Diodati sums up the recent SPML threads here. But one questions that needs to be answered, if not SPML then what? One alternative that has been put forward by Mark Diodati, Mark Wilcox, and others is the LDAP (or DSML) pull model of provisioning.

This model is to expose your user accounts via LDAP using a Virtual Directory (VD) instance exposed to your service provider. The service provider would periodically make calls to the VD to look for account CRUD operations.

There are several compelling advantages to this model;

  • LDAP is already a standard protocol
  • There are defacto standard schemas (the most common of which is the standard AD account)
  • This is really just an extension of a model that has already been embraced in the enterprise (look at how many apps can be AD enabled)

Could that be it? Is the solution to service provider provisioning really this simple? No, at least not without SAML. While this model shows promise there is a problem; passwords. If your enterprise is not ready to use SAML to authenticate to your service provider, then you are left with two choices; both unpleasant.

First you could just punt on passwords and force your users to manage their passwords on their own. This is no worse than the situation without any provisioning, but certainly not where you could be if you used a provisioning solution to push the passwords out to the service provider as needed.

The second is to expose your password hashes via your VD. If your service provider supports the same salting and hashing algorithms, then the passwords could be synchronized by copying the hash across. In fact the recent version of the Google apps dir sync utility claims to be able to do just that.

But think about this for a moment. If you do that then the service provider knows the clear text password to log into your network for every one of your users that actually uses the service. After all, the user has to provide the clear text password to the service provider’s login page to generate the hash value to compare to the hash you sent them. If that’s the same as the hash value in AD, then the service provider knows your AD password by definition.

Do you trust Google with the clear text AD passwords? I’m not picking on Google; there simply aren’t any service providers I would trust with that information.

Another alternative I have heard is that the service provider’s login page would make an LDAP bind call back to the VD with the supplied password to do the authentication. Again, that gives the service provider a clear text version of your AD password.

Are you sure you really want to do that?

But if your enterprise and your service provider can implement SAML, then the LDAP pull model looks a lot more compelling. I would be curious to hear from anyone that has implemented this or is thinking of implementing it. And if anyone is using the password hash sync approach, I would be interested in hearing about as well.

→ 6 Comments

Posted in AD, Authentication, Google, Identity, Password Management, Provisioning, SAML, SPML, Standards, Virtual Directory

Tagged , , , , ,

Whither SPML or wither SPML?

Posted on February 12, 2010 | 5 Comments

Whither SPML or wither SPML? This is the question Mark Diodati asks in his post SPML on Life Support. Ingrid Melve and Nishant Kaushik have follow ups here and here.

The problem with SPML still the same more than 10 years after the effort was started. Right now the choice is between home grown provisioning or bringing in a provisioning vendor. In the latter case the provisioning vendors are forced to absorb the pain of integrating to all the disparate provisioning targets (a pain I know all too well). Since the provisioning vendors make it all work, the customers don’t force the enterprise system vendors to add SPML interfaces.

Note that Nishant has this to say about Oracle:

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.

Great, I would love to see that happen. But Oracle has been involved in SPML from the beginning, but do you know what they haven’t done? Added an SPML service to to support the provisioning of Oracle DB accounts. Neither has IBM, Sun, or Microsoft with respect to their own DB products, even though they have all had involvement in the SPML standard over the years. It’s the same when you look at directories, email systems, etc.

We can talk about the standards or “pull models” all we want, but it takes two to Tango. Until the enterprise systems support a common interface of some kind, provisioning will still be as problematic as it was 10 years ago.

→ 5 Comments

Posted in Identity, Identity Management, Provisioning, SPML, Standards

Tagged , , ,

SPML, SAML, OAUTH, and Impedance Mismatch

Posted on December 3, 2009 | Leave a comment

Nishant Kaushik posits an interesting question; can OAUTH fill the provisioning role in Just-in-time federated provisioning. Mark Wilcox follows up here and here.

I agree with Mark’s commenter who suggests that a SAML attribute service fills the role just as well. Mark suggests that a SAML attribute query is too difficult to implement in some development environments. But I am not sure that I buy the argument that there are environments where doing the SAML SSO is doable but doing the attribute query isn’t.

Regardless all this got me thinking about impedance matching. When we wear our standards hat, all things are possible. But we need to step back at times and put on our developer hat and think about how are designs are going to be implements. While we could mix SAML and OAUTH to support JIT federated provisioning, implementation now requires tools, libraries, and implementers that can implement both SAML and OAUTH as well as handle the rough edges where the don’t mesh well. That’s an impedance mismatch in my opinion.

→ Leave a comment

Posted in Authentication, Identity, Open Source, OpenID, Provisioning, SAML, SPML, Standards

Tagged , , , , , , ,

Good summary of Sun’s open IdM projects

Posted on November 24, 2009 | Leave a comment

Luca Mayer has this summary of Sun’s open source IdM projects. I have some experience with OpenSPML (obviously), and I have fiddled with OpenDS. There is some great stuff there.

I hope this all survives the acquisition.

→ Leave a comment

Posted in Identity, Identity Management, Open Source, Software, SPML, Standards

Tagged , , , , , ,

Physical and logical security convergence

Posted on July 9, 2009 | Leave a comment

Guy Huntington has had a lot of interesting things to say recently over at his AuthenticationWorld blog. I am not sure I completely agree with this, however:

Get all my PAC products to meet LDAP, SPML and XACML protocols.
This enables the products to easily interconnect with any of the logical identity and access management products. Most are now LDAP (Lightweight Directory Access Protocol) enabling communication between the enterprise directory and the PAC.

I’m not sure how compelling it is to SPML enable a product that is already LDAP enabled. As much as I like SPML, if the PAC identities are already externalized to LDAP, I’m not sure I see the value in provisioning via SPML.

Still, Guy makes some great points about the value of integrated PAC, Identity, and Security Management systems.

→ Leave a comment

Posted in Identity, Security, SPML

Tagged , , , , ,

SaaS provisioning

Posted on June 30, 2009 | 1 Comment

Jackson Shaw makes the point that the last thing that most enterprises need is to take on is provisioning their SaaS identities when they are still struggling with their internal identities:

We have a standard called “Services Provisioning Markup Language” (SPML) which was specified to help provision identities via a web service. Does your SaaS vendor support that standard? I’ll bet they do not! What do you do then? I’ve met with hundreds of customers over the years and many are still struggling with provisioning inside the enterprise! Throw in SaaS provisioning – via some hairbrained interface because the vendor doesn’t support SPML – and it only adds to the organization’s identity management complexity.

Of course having an SPML capability in a SaaS is not going to be much help if the enterprise doesn’t have a provisioning system in place with SPML support. SPML support is not widely available in provisioning systems (although there are a few that have it out of the box).

Ashraf Motiwala echoes the point and also points out that enterprise are going to want to leverage not only their internal provisioning systems, but also their workflow and role management systems as well:

Recreating a workflow engine, role management, delegation, etc. in the cloud seems to just create redundancy for these capabilities, especially for organizations that have already dropped a few dollars to deploy an IdM solution on premise. Why would I drop my existing investment here? (Perhaps there is a compelling case, but I just don’t see it.) I would much rather find a solution that proxies the SPML requests from my existing provisioning solution that handles all the complexities (or “hairbrained interfaces”) for the SaaS apps on the backend!

The upshot is that SaaS vendors should be rolling out SPML interfaces to their services. But just like with the traditional enterprise software vendors, they most likely won’t do it until the customers demand it. Until it becomes a selection criteria it probably won’t happen.

→ 1 Comment

Posted in Identity, Identity Management, Provisioning, SaaS, SPML

Tagged , , , ,

It’s the model stupid

Posted on April 29, 2009 | Leave a comment

William Vambenepe has a great write up on past and current IT management standards efforts here (and rifs on the famous Bill Clinton internal campaign motto):

I wish that rather than being 80% protocols and 20% models, the effort in the WS-based wave of IT management standards had been the other way around. So we’d have a bit more to show for our work, for example a clear, complete and useful way to capture the operational configuration of application delivery services (VPN, cache, SSL, compression, DoS protection…). Even if the actual specification turns out to not make it, its content should be able to inform its successor (in the same way that even if you don’t use CIM to model your server it is interesting to see what attributes CIM has for a server).

It’s less true with protocols. Either you use them (and they’re very valuable) or you don’t (and they’re largely irrelevant). They don’t capture domain knowledge that’s intrinsically valuable. What value does WSDM provide, for example, now that’s it’s collecting dust? How much will the experience inform its successor (other than trying to avoid the WS-Addressing disaster)? The trend today seems to be that a more direct use of HTTP (“REST”) will replace these protocols. Sure. Fine. But anyone who expects this break from the past to be a vaccination against past problems is in for a nasty surprise. Because, and I am repeating myself, it’s the model, stupid. Not the protocol. Something I (hopefully) explained in my comments on the Sun Cloud API (before I knew that caring about this API might actually become part of my day job) and something on which I’ll come back in a future post.

I can sympathize with William. I wish that in the SPML effort we had spent more time working on the model up front. The plan had always been to finalize the protocol and then work on the model. As a result the model work never really got properly addressed, although there is a possibility it might someday.

→ Leave a comment

Posted in CMDB, SPML, Standards

Tagged , , ,

Janus versus Vulcan in Federated Provisioning

Posted on February 7, 2009 | 2 Comments

I always thought the Roman God Janus should be the patron deity of security professionals. From the Wiki page on Janus:

In Roman mythology, Janus (or Ianus) was the god of gates, doors, doorways, beginnings and endings. His most prominent remnants in modern culture are his namesakes: the month of January, which begins the new year, and the janitor, who is a caretaker of doors and halls.

Likewise I see Vulcan as the symbol of those toiling in the system integration and provisioning fields. Crafting unsexy and necessary technologies that make disparate IT systems work together. From the Wiki page on Vulcan:

The Romans identified Vulcan with the Greek smith-god Hephaestus, and he became associated like his Greek counterpart with the constructive use of fire in metalworking.

This comparison came to me as I was reading the recent flurry of posts about Federated Provisioning. You can go here to read the latest from Dave Kearns, Pamela Dingle, Ian Glazer, and Nishant Kaushik. These are some really smart people who make some good points, but they are mostly talking past each other. This is a Mars versus Venus kind of debate, only it’s really Janus versus Vulcan.

The federation (Janus) side of the federated provisioning discussion tends to favor the just-in-time-provisioning, minimal disclosure, and privacy aspects of federation. The provisioning (Vulcan) side of the federated provisioning focuses on the total life-cycle of the identities known to both the service provider and consumer.

That’s not to say either is right or wrong. Both have good points. But there are serious holes in the just-in-time provision approach and Pamela’s just-on-usage deprovisioning suggestion. Let me give you an example to illustrate.

Suppose ACME is outsourcing one of its sales application. Now support the SaaS application has a feature that lets you (as a sales manager) assign a sales lead to one of your salesmen. Right off the bat you should see the first problem. How do you get the salesman’s information into the system if he has never performed the federated authentication step (I am intentionally being protocol agnostic here). Clearly ACME must have bulk provisioned all the salesmen to the application when setting up the service.

But what happens when a new salesman is hired? A provisioning process should be in place to provisioning the new salesman to all the SaaS services that need to know about him. But what happens if the new salesman doesn’t work out and is let go? Cleary ACME doesn’t want to him to still show up in the list of people that sales leads could get assigned to. Just-in-time-provisioning and deprovisioning just won’t be sufficient for many applications because the identity information needs to be synchronized before the user performs his first authentication. This can be true of any application where the users interact with each other.

In addition to the data synchronization problems in Federated Provisioning, there is also the auditing issue. How does ACME audit what its salesmen did in the application? Right now there isn’t a standard that covers “Federated Auditing”, but I predict that it is something customers are going to start asking for if the truly embrace SaaS.

I guess you could say I am more Vulcan than Janus.

→ 2 Comments

Posted in Identity, Provisioning, SaaS, SAML, SPML, Standards

Tagged , , , , ,

SPML gateways move forwards

Posted on January 30, 2009 | 4 Comments

Mark Diodati points out this interesting open source SPML gateway. There is an accompanying blog by Jerry Waldorf of Sun that has a lot of background on the project and presents some interesting concepts of things that you could do with an SPML gateway.

This is exactly the kinds of stuff I had hoped to see happen when I started working on SPML. Working at Access360 it was frustrating to see so much time and effort spent writing connectors to all the disparate systems that needed to be provisioned. If only project keychain had existed back then.

Great stuff if you are interested in provisioning.

→ 4 Comments

Posted in Identity, Identity Management, Open Source, Provisioning, SPML, Standards

Tagged , ,

If only, if only

Posted on January 27, 2009 | 1 Comment

I like skeptics. I like to consider myself one. I also thoroughly enjoy reading the IT Skeptic. But this borders on pure fantasy:

Then there is the question of the pace at which this beast is moving. Although the document referenced here is dated October 2008 the changelog ends in January 2008, and it is certainly the only output we have seen this year other than one(?) multi-vendor demo. There are zero commitments from DMTF or from the vendors for any sort of timeline for delivery of anything. As I have pointed out in the past,

“WARNING: vendors will waive this white paper around to overcome buyer resistance to a mixed-vendor solution. For example if you already have availablity monitoring from one of them, one of the other vendors will try to sell you their service desk and use this paper as a promise that the two will play nicely. “

All I could think of when I read this was “If only”. If only the vendors cared enough about interoperability standards to make it a selling point. Then you might eventually get real interoperability, even if it started as vaporware.

But the reality is the front line sales guys usually don’t know or care about standards, past checking boxes in an RFC. William Vambenepe sum’s it up nicely in this rebuttal:

Has anyone actually seen this happen? I am asking because so far, both at HP and Oracle, the only sales reps I have ever met who know of CMDBf heard about it from their customers. When asked about it, the sales person (or solutions engineer) sends a email to some internal mailing list asking “customer asking about something called cmdbf, do we do that?” and that’s how I get in touch with them. Not the other way around.

Also, if the objective really was to trick customers into “mixed-vendor solutions” then I also don’t really understand why vendors would go through the effort of collaborating on such a scheme since it’s a zero-sum game between them at the end.

I don’t mean this to be critical of the sales guys. They care (as they should) about the requirements the customers care about. Until the customers start making support for interoperability standards like CMDBf (in the ITSM space) and SPML (in the IdM space), these standards will never get robust implementation. And the customer will continue to get stuck with siloed solutions.

→ 1 Comment

Posted in Change Management, CMDB, SPML, Standards

Tagged , ,