Ask HN: LDAP Directory as a Service?
3 comments
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.
Offloading, and outsourcing, some things makes sense. But authentication data? That just seems unduly risky.
Offloading, and outsourcing, some things makes sense. But authentication data? That just seems unduly risky.
Thanks Steve, appreciate your feedback. You're right, data and system availability are primary concerns, and ldap.io is designed with those factors in mind.
In the event of networking or connectivity problems -- for example, if your Internet link goes down -- we're considering providing an on-premise virtual appliance configured to automatically replicate with the hosted servers. It would be very low maintenance and a good option for BCP.
For the authentication issue in general, consider the current trend of Identity as a Service and Single Sign-on as a Service -- Okta, OneLogin, and Ping, to name a few. If you use ldap.io for authentication, it would be in the same category of services, and you would also have more control of the data layer.
Along the same lines, Microsoft is now offering Active Directory for Windows Azure, to cater for similar use cases in the Windows world. See http://www.windowsazure.com/en-us/services/active-directory/
In any case, totally understand your concerns, and it makes sense to use the service for non critical purposes, in the first instance.
In the event of networking or connectivity problems -- for example, if your Internet link goes down -- we're considering providing an on-premise virtual appliance configured to automatically replicate with the hosted servers. It would be very low maintenance and a good option for BCP.
For the authentication issue in general, consider the current trend of Identity as a Service and Single Sign-on as a Service -- Okta, OneLogin, and Ping, to name a few. If you use ldap.io for authentication, it would be in the same category of services, and you would also have more control of the data layer.
Along the same lines, Microsoft is now offering Active Directory for Windows Azure, to cater for similar use cases in the Windows world. See http://www.windowsazure.com/en-us/services/active-directory/
In any case, totally understand your concerns, and it makes sense to use the service for non critical purposes, in the first instance.
I think this would be much more interesting if you could provide it as a product (i.e. LDAP in a box) rather than purely as a service.
We're definitely considering that, but we don't want to be just another enterprise LDAP vendor. What would be the unique selling point, in that case? Elasticity?
The Platform as a Service angle is very interesting, and we're planning to release an addon for the major platforms such as Heroku, GAE, OpenShift, and CloudStack. CloudStack is already setting a precedent with their new LDAP authentication functionality. We'll see if it catches on.
The Platform as a Service angle is very interesting, and we're planning to release an addon for the major platforms such as Heroku, GAE, OpenShift, and CloudStack. CloudStack is already setting a precedent with their new LDAP authentication functionality. We'll see if it catches on.
Do you also offer Kerberos?
Kerberos wasn't planned, but we'll definitely consider it if sufficient interest is shown.
You do 389 Directory server, I was just thinking of http://freeipa.org
Looks like a cool project, will check it out.
At the moment, ldap.io is intended as more of a general purpose infrastructure service, rather than strictly identity or authentication.
At the moment, ldap.io is intended as more of a general purpose infrastructure service, rather than strictly identity or authentication.
We're preparing an infrastructure service for LDAP directories, similar to AWS's Relational Database as a Service (RDS).
Why? Well, there are some compelling use cases for Directory as a Service. Here are a few examples:
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.
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.
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.
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
Here's what's currently planned on the roadmap:
- 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
We'd love your feedback, whether positive or negative. Thanks.