41–50 of 61 posts
Earlier quoted context omitted.
Misguided? The microservice you suggest is precisely what the post suggests. The post suggests that the code of the microservice ensures that the correct hashing is used and that the data is stored correctly. It's puzzling that you say this is "completely misguided" and describe exactly the same thing.
OP called for "a specialized database". I was talking about using the same kind of database.
Earlier quoted context omitted.
My uninformed perception of OpenLDAP is that it is a large, generalised enterprise class directory service that does alot of stuff. The post suggests a minimal, lightweight user database that does nothing at all else - is that the same thing as OpenLDAP?
Pretty much. I wouldn't characterize the magical detection of uncommon access patterns as a minimalist feature (it can be done, but not out of the box in a meaningful way), but other than that, all of the stuff you mentioned is there. Typically, you use LDAP as a directory store, and a dedicated authentication protocol like Kerberos or SAML for authentication. You can also use LDAP for auth if desired. If you want to…
I'm not even sure about a meaningful way. For sake of portability the DB will need to have some way to dump everything. And if a server admin can do that, then someone who can get the same access as a server admin can do it, and we're back to square one.
There is such a beast, it's called LDAP. There are any number of directory and authorization services, and they have probably been around for decades. There are dozens of directory server options, and probably a few dozen secure authorization solutions, from Kerberos and SAML to proprietary solutions like SiteMinder. Together, these solutions give you EIAM capability that does what you described.
While technically you're right (as in, LDAP is great for handling many user entries and auth[nz] correctly), in practice it's not going to happen. Nobody knows LDAP (as in, take a random sample of non-corporate developers and most likely none of them will know LDAP). It's a pain to integrate and operate in a small environment. That's why there's a call for a simple solution. It's why everyone uses JSON and not ASN.1.…
And that's just when you're using the recommended connectors (ODBC/ADO.NET). FSM help you if you're using JDBC and the vendor of the $20k+ product hasn't tested against Server 2012.
I wonder if there's any money in providing an LDAP/AD -> REST server.
http://stackoverflow.com/questions/2453769/active-directory-... might be an idea, too.
There is such a beast, it's called LDAP. There are any number of directory and authorization services, and they have probably been around for decades. There are dozens of directory server options, and probably a few dozen secure authorization solutions, from Kerberos and SAML to proprietary solutions like SiteMinder. Together, these solutions give you EIAM capability that does what you described.
Can existing LDAP implementations scale a single directory to hundreds of millions of users? I can find no clear answer after a few minutes of searching.
OP here. It's a fairly simple concept - any wizards with a few spare hours willing to try to put a prototype together today? From HN front page to solution within hours! If it said "built with Golang" or "built with Rust" it would certainly hit the front page.
My beta-quality Golang version of this with pluggable backends, including S3: https://github.com/nmcclain/glauth I would love suggestions/help.
OP here. It's a fairly simple concept - any wizards with a few spare hours willing to try to put a prototype together today? From HN front page to solution within hours! If it said "built with Golang" or "built with Rust" it would certainly hit the front page.
My beta-quality Golang version of this with pluggable backends, including S3: https://github.com/nmcclain/glauth I would love suggestions/help.
thanks
1. s/specialized/separate/
2. Use SASL, or another authentication protocol to talk to your auth DB.
3. Profit!
Re: LDAP
This may not be as good as a specialized solution, but it's probably a step up from throwing all your data into the same MySQL DB. ;-)
It's not particularly hard, either, just different from what you may be used to.
There is such a beast, it's called LDAP. There are any number of directory and authorization services, and they have probably been around for decades. There are dozens of directory server options, and probably a few dozen secure authorization solutions, from Kerberos and SAML to proprietary solutions like SiteMinder. Together, these solutions give you EIAM capability that does what you described.
Can existing LDAP implementations scale a single directory to hundreds of millions of users? I can find no clear answer after a few minutes of searching.
So, practically speaking - does it matter?
[0] And equivalent for each country with >70M people
There is such a beast, it's called LDAP. There are any number of directory and authorization services, and they have probably been around for decades. There are dozens of directory server options, and probably a few dozen secure authorization solutions, from Kerberos and SAML to proprietary solutions like SiteMinder. Together, these solutions give you EIAM capability that does what you described.
Can existing LDAP implementations scale a single directory to hundreds of millions of users? I can find no clear answer after a few minutes of searching.
Earlier quoted context omitted.
My beta-quality Golang version of this with pluggable backends, including S3: https://github.com/nmcclain/glauth I would love suggestions/help.
Ned - would you mind replying to this with a list of the features specified in the blog post and a YES/NO to confirm which are supported by your code? thanks
It should not provide generalised database query functionality. YES - it only proivdes the subset of LDAP functionality necessary for authentication.
Its API should have password salting and hashing built in. NO - hashed but needs salting&scrypt.
Its API should throttle access with some sort of algorithm designed to prevent downloads of large quantities of user data. NO - todo.
It should encrypt data internally. YES (hashed not encrypted).
It should communicate only over encrypted connections. YES.
It should be distributed. YES.
It should not be run on any web server, should run "behind the scenes" and be accessible only via its API. YES.
It should include triggers and alerts based on uncommon access patterns or recognised nefarious access patterns. NO - todo.
It should have no other purpose. YES.