Pulling LDAP

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.

Advertisements

6 responses to “Pulling LDAP

  1. We are actually implementing a Virtual Directory w/ an LDAP interface fronted by an XML Security Gateway that is exposing a SAML Interface. Works very well and gives us a variety of benefits including a standardized interface to expose to the “outside”, ability to layer WS-Security based AuthN, AuthZ and more..

  2. Thanks for the feed back. But I was actually looking for examples of exposing a VD directly to a service provider rather than being hidden behind a SAML service (or some other interface).

  3. I’m curious about the LDAP interface. Do you mean the service provider is allowed to make binds and searches directly against the LDAP schema? So there’s not much use for SAML or federation?
    Surely that wouldn’t scale on the SP side and how would it know what LDAP to bind to if it has relationships with several?
    Or this is not a federated scenario? Sounds interesting anyway as I was involved in just such a scenario where an SP wanted direct access to an LDAP directory but we convinced them federated access was better for them in the long run, using SAML.
    Also, identity can be created by the combination of several LDAP attributes , the rules to do so only the source organisation should know about.
    Direct LDAP access is fine for authn but authz is too complicated to duplicate identity rules at multiple SPs.

  4. hey – I posted my comment with the wrong email and blog! what a numpty!

  5. Pingback: SAML vs XACML for ABAC & AuthZ « Identity Sander

  6. Cool point! My company (and my project) have actually implemented this. Our product uses simpleSAMLphp with our flagship web-portal software to create a slick user and services portal.

    One of our configuration options is to use an Active Directory domain as an authentication source instead of our default database back-end. The net result is a SAML-ActiveDirectory bridge.

    For the purposes of discussion, this means that I can use Google Apps, with the existing user names and passwords already provisioned in my Windows Domain without exposing my passwords to Google.

    I’ve always been a little horrified of the sync-based design they offered by default.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s