Design a way to allow a user to programmatically share a grain with a new user account

sandstorm-io / sandstorm

Sandstorm is a self-hostable web productivity suite. It's implemented as a security-hardened web app package manager.

https://sandstorm.io

Other

6.75k stars 706 forks source link

Design a way to allow a user to programmatically share a grain with a new user account #1791

Open paulproteus opened 8 years ago

paulproteus commented 8 years ago

The general use-case here:

As a user of a grain,
And as a programmer,
I want to create an external-to-Sandstorm service that can interact with a Sandstorm grain and create a new user account for someone, and share-by-identity the grain with them,
So that I can create business process automation to "onboard" a new organization member into my organization, including access to a grain that they will need access to as part a member of my organization.

There a few ways this could be accomplished. I'm filing this bug so that we have a name for this goal, not because I have a specific design to suggest.

But having said that, one interesting fact is that Sandstorm has no "API" of its own for a user, which makes it hard to automate it. One could use Meteor methods if one really wanted to, but we don't seem to document that as a good idea.

This ticket tracks the task of deciding on a design that we like well enough for this purpose.

ocdtrekkie commented 8 years ago

Well, in a corporate setting (Active Directory), I'd pre-create their account, log in as them and set things up, then reset their password. For LDAP users, this is plausible.

This doesn't work for credentials not controlled by your organization though.

(This isn't really a "proposed solution" so much as a documentation of the workflow I'm used to as an admin who does these things.)

dwrensha commented 8 years ago

One place to put this functionality would be in methods on either SandstormApi or SessionContext. If you want to be able to perform these actions external to Sandstorm, you could have a grain that exports the functionality as an HTTP API.

kentonv commented 8 years ago

Probably should be a powerbox-requested API rather than on SandstormApi, but yes, I think the right place to start is by defining a Cap'n Proto API which can be consumed by a grain, which could in turn export an HTTP API if external control is desired.

It might make more sense to structure as an "on create user hook" rather than a "create user API", since Sandstorm normally creates users on-demand when they first log in...

paulproteus commented 8 years ago

onCreateUser hook is interesting, but note that sometimes external software wants to create identities so that it can share a grain by identity, since share-by-identity is (in my opinion) a much easier-to-use experience than share-by-link-then-remember-to-redeem-the-link.