Do you work with LDAP, or are you considering it? If so, this might be useful to you.<p>We're preparing an infrastructure service for LDAP directories, similar to AWS's Relational Database as a Service (RDS).<p>Why? Well, there are some compelling use cases for Directory as a Service. Here are a few examples:<p>1. Offloading the operation of non-production LDAP directories to a managed service. For example, any development or test directories that you would usually create and/or operate yourself.<p>2. Designing a cloud-first application that uses an LDAP directory as a data store. One of the most popular uses of LDAP is managing users and authentication (think Microsoft Active Directory) -- and for good reason. LDAP is optimised for searching, with very fast retrieval of users and other indexed objects.<p>3. Relocating an existing on-premise application to the cloud, where the application uses an LDAP directory as a data store. The benefits are the same as in the cloud-first use case.<p>While we're in beta, we're happy to spin up a free directory for you to try. The LDAP flavour is 389 Directory Server, which is the open source version of Red Hat Directory Server. You can apply for a free trial directory at http://try.ldap.io/beta<p>Here's what's currently planned on the roadmap:<p>- Administration dashboard
- Single tenancy
- Different LDAP flavours (OpenLDAP, 389 DS, OpenDJ, OpenLDAP)
- Scaling and replication (master-master, master-slave, provider-consumer)
- REST and JSON-RPC APIs
- Cloud agnostic infrastructure (AWS, Google Compute Engine, etc)
- Friendly web client
- Dead simple schema updates
- Premium support<p>We'd love your feedback, whether positive or negative. Thanks.
Not only would we have to consider you losing our data we'd have to consider that our logins would go offline if we had networking issues between ourselves and your location.<p>Offloading, and outsourcing, some things makes sense. But authentication data? That just seems unduly risky.