Sandstorm for Work Beta: LDAP, SAML, Organization Management | Hacker News Reader

Sandstorm for Work Beta: LDAP, SAML, Organization Management

sandstorm.io

131 pointsjgillich17 comments

Hmm, I'm a huge fan of sandstorm, but I have mixed feelings about this. I like sandstorm for its promise of easily running my own apps on my own server. My data is private and secure, yet I can still access it from my phone, laptop, library, etc. And a lot of really smart people are spending a lot of time making this happen, so in some ways I'm happy that they have a monetization strategy and strong motivation to keep at it!

On the other hand, until now, I had thought their monetization strategy was their oasis hosting platform. But now that I see this "sandstorm for business" strategy, it seems there's at least a little incentive to hamstring the non-business side to encourage people to purchase the feature key. The incentives aren't exactly aligned anymore. Before, I thought that any development that improved the platform would increase oasis use, and be good for them and good for private self hosters. Now, development on the "for business" features is much better for them with no benefit to people who haven't purchased the key, so I think there might be more developer focus on it.

On the other other hand, I can't think of a better way of going about it. Kudos to them for keeping it open source, being up front about the license check, and having the auto-update strategy. I like that if a business wants to stop paying, they're essentially locked into what they had paid for to that point, but haven't lost their data or access to the features they had. They just stopped paying for ongoing development so they don't get future features. That's pretty neat.

Overall, I don't see anything wrong about this approach, and a healthy sandstorm ecosystem and happy sandstorm devs is good for everyone, including those self-hosting the free version. It's just now I have a tinge of disappointment thinking of all this great development I was getting for free before, that now might be spent on enterprise features not available to me.

My thought: They're trying to be Red Hat, except intentionally making their CentOS easy and inevitable.

That's a disturbing, but interesting, thought. I wonder how often this has played out. Might be worth considering explicitly in a risk assessment of OSS-centric startups.

Note that while the set of "enterprise add-ons" we launched today are open source, we are not promising that all future add-ons will be open source. In particular future products we have planned that specifically target the needs of very large organizations may be proprietary. Once the contracts are so big that it's cheaper for the corp to maintain their own fork, then obviously our stay-open strategy breaks down, but we have a plan for that. (That said, I'm still looking for ways to make it work as OSS if possible.)

Sandstorm founder here. Thanks for your feedback -- I definitely understand the concern, and it's something I've thought about a lot.

To be clear, we've always been upfront about our intent to sell "enterprise add-ons" to the self-hosted solution. See this post, from January 2015:

https://sandstorm.io/news/2015-01-15-sandstorm-1.3M-seed-rou...

It is our intent that any feature which is broadly useful to someone running a personal server should be in the free version. There is a gray area, of course: some people actually run LDAP servers in their homes. But we're pretty sure that the vast majority of personal users won't be interested in these business-oriented features. And we have a lot of potential features to implement that businesses need but individuals absolutely don't (examples: legal discovery tools; HIPAA compliance; cluster management), so there's really no need for us to hold back the more broadly-useful features for leverage.

I'd actually argue that it would be very much against our interest to "hamstring" the personal version of the product, not just morally but strategically. Strategically speaking, we aren't going to make much money off personal users no matter what pricing we impose. Business is where the money is. Personal users are incredibly important, though, because the kinds of enthusiasts who would run their own Sandstorm server are also the kinds of people likely to develop apps and/or advocate for Sandstorm to their employer. It would be shooting ourselves in the foot to do anything to turn off those users.

Of course, strategy isn't the only thing holding me back. Morally speaking, I personally started Sandstorm to make open source web apps viable, not to get rich. See:

https://sandstorm.io/news/2014-07-21-open-source-web-apps-re...

To be honest, I would actually argue that our hosting service is a bigger conflict of interest than Sandstorm for Work. It could make us inclined to make it hard to set up and maintain Sandstorm -- why spend time making installation painless and updates automatic if it only benefits the people who aren't paying us? Sandstorm for Work is actually the exact same build as the free version, with the same installation process, so now we're incentivized to keep it really easy -- and indeed, last night we shipped an overhaul of our first-time setup UX, which we did for the Sandstorm for Work launch, but it applies to the free version too.

All in all, of all the options we've considered, I think this approach actually gives us the best alignment of incentives.

Well put! I applaud you for making the for work version open source. At GitLab we found that this helped during the introduction but was confusing to customers in the long run. I'll watch closely how Sandstorm handles this and we'll try to learn. Congratulation on this move today, I think it makes a lot of sense. For us the on-premises premium version allowed us to become sustainable, I hope it will do the same for you.

I'm uneasy about this too (the ldap part in particular). It's an odd sensation, when the first contribution you want to make to a great FOSS project is to fork it and work around a nagscreen and provide a channel for updates ...

More generally, I really think a solid self-host federated login solution should be part of any project of Sandstorm's nature. Granted, there aren't really any pleasant out-of-the-box reasonably secure (as in, sane ldap schema permissions, tls-only) FOSS ldap solutions. In this regard Microsoft AD might still be the easiest option for many small businesses. Although Red Hat at least has a story here, that (thanks to being FOSS) should/does work across distributions.

I certainly sympathize with the idea that it's hard to know where to draw the line for which features are "value-add", and how to charge for them in a mostly open platform. And I'm afraid I can't really come up with anything more constructive as an alternative right now.

Still hope Sandstorm will continue to evolve, it's a very interesting product!

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.

I 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.

Hmm... How many users do you manage this way? If we had a "free up to 10 users" sort of thing, would that work?

I 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.

Definitely under 10, so that would be perfect!

In 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/msg00...

Source code here: 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.

> To be honest, I would actually argue that our hosting service is a bigger conflict of interest than Sandstorm for Work. It could make us inclined to make it hard to set up and maintain Sandstorm -- why spend time making installation painless and updates automatic if it only benefits the people who aren't paying us?

Hm, that's a good point! Along with your seed round funding post linked in your comment, that makes a lot of sense. Thanks for the response.

Too bad the pricing is not as smart as the technology: Look at splunk, it's free for small usage, to get people started, just as google apps used to be, then when half or the whole company depends on the tool, then it starts to cost money, and quite a lot. That's better, softer approach.

Anyway, kudos to sandstorm, what they built is awesome.

Thanks for the feedback!

Honestly if you are, say, 5-10 people, you'll get by just fine with the free version of Sandstorm. You can log in using an email address or Google or Github account.

I think things like LDAP integration, access control lockdowns, and audit logging start becoming important when you want to have, say, 50 people or more on the server together, with a dedicated IT person or team managing it.

We should probably work on making that clearer in our marketing copy, though!

Things like LDAP are often in the enterprise version of open apps. I sometimes wonder if self-contained implementation if those features simple to integrate and deploy would disrupt that. Disrupt the companies disrupting everything else! Haha.

Not sure, though. It might still be a pain on a per-app basis to get enterprise features working.

Reply on news.ycombinator.com