3 ms·
I think for an at-home setup, we should be able to come up with something much simpler and better-suited to the task than LDAP. I'm happy to add new and well-de
by kentonv 11y ago
I think for an at-home setup, we should be able to come up with something much simpler and better-suited to the task than LDAP. I'm happy to add new and well-designed login systems to the free version. The main tricky requirement is that we want identities to be global -- that is, other people's Sandstorm servers should be able to authenticate you to the same global ID that your own server does. This is important so that it's possible to transfer grains between servers without all the user IDs changing (which probably makes the grain useless, if it stores user IDs at all). (Actually, LDAP doesn't even satisfy this requirement! But we figure corp users aren't as eager to participate in a federated network of personal servers.)
One thing we want to add, for example, is public-key login, where your identity is your public key fingerprint. You login in by proving access to the private key. Though, this is something I'd only recommend for hardcore crypto nerds, since bad key management would be catastrophic. We should look into other options, too.
- mynameisvlad 11y agoI personally have AD set up for my entire family since it comes with goodness like Group Policies and allows me a certain degree of control and uniformity even hundreds of miles away. It'd be great to be able to use the same logins for Sandstorm. Just my anecdote, fwiw.
- kentonv 11y agoHmm... How many users do you manage this way? If we had a "free up to 10 users" sort of thing, would that work?
- philprx 11y agoI think that would be a great way to kick start orgs into this business offering. Google made it open for 100, then 50 then 25 then paying for each one iirc. The early adopters kept their free version until reaching that limit.
- mynameisvlad 11y agoDefinitely under 10, so that would be perfect!
- e12e 11y agoIn general I agree that LDAP(S)+Kerberos isn't a very good solution for federated ID management, but I'm not aware of anything that's better, that allows sharing an id for system logon, email logon, web-app-logon etc easily. Even for a home setup. > This is important so that it's possible to transfer grains between servers without all the user IDs changing (which probably makes the grain useless, if it stores user IDs at all). I see only two sane ways to deal with that: map users to GUUIDs (so logins becomes aliases) - or use user@domain (essentially email addresses). Maybe even both at once. One thing I've been meaning to look into, is Debian's (the projects) new SSO solution, announced here: https://lists.debian.org/debian-devel-announce/2015/08/msg00011.html https://lists.debian.org/debian-devel-announce/2015/08/msg00... Source code here: http://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/ http://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tre... > One thing we want to add, for example, is public-key login, where your identity is your public key fingerprint. Uh, see above. Even ssh doesn't do that - it binds a key to a login. Building on top of ssh certificates might be a way - but not really for web-apps I think. I shudder to imagine how one would try to handle ssh-keys securely via the browser, that has bad enough support for X509 certificates. In general I think these are two problems, were one might be a superset of the other: Allow users to set up federated/centralized login/authentication and authorization for all systems, including system login (the system login screen, console login) - the other being allowing users to integrate with an SSO for web apps. Ldap generally allows for both of these, while other solutions, like eg: facebook-login doesn't in the general case make sense for system login.