4 ms·
+1 for hosted LDAP as a service (maybe even backed by GApps). New startups typically tend to go with Google Apps for their email needs. Google exposes authenti
by amoghe 12y ago
+1 for hosted LDAP as a service (maybe even backed by GApps).
New startups typically tend to go with Google Apps for their email needs. Google exposes authentication via OAuth2. However many services (specifically developer tools such as gerrit, jenkins) do not support OAuth2 yet (only OpenID, which sadly Google deprecated some time ago) and LDAP. Having an LDAP frontend to provide identity/auth so that startups can use a single set of credentials across their internal applications would be nice.
TL;DR - LDAP frontend to Google identities would be nice. From when I last checked (few months ago), no one offers this.
- sujoyg 12y agoGreat feedback @amoghe. If this was a full LDAP as a Service, which synced with Google Apps, rather than just an LDAP adapter, would that make sense?
- amoghe 12y agoBased on our current needs, no. What we are/were looking for is a service that could provide LDAP "frontend" to Google Apps identities so we can have a single set of credentials across services (and email etc). Seeing as how nothing of that sort exists, an LDAP(aaS) would also suffice, but not be ideal because: (a) we would end up using only a small subset of the LDAP functionality (namely auth). (b) seeing as how none of the early engineers have administered a (full blown) LDAP service, someone would have to climb this curve. I'm curious why cloud based identity management solutions don't offer this (eg. okta). However I wont claim to know/understand the full breadth of their offering and whether this aligns well with their business.
- badusername 12y agoSeems like what you are describing is already possible by using single sign-on providers like onelogin and okta.
- amoghe 12y agoAlmost. AFAICT both OneLogin and Okta do not provide LDAP-like access to their identity service. Unfortunately we're running a couple of services that authenticate using either LDAP or an internal user database. We're stuck using the latter option (for now).