On Thu, May 29, 2014 at 7:46 AM, Tim Penhey <[email protected]>wrote: > > In the future we will have servers that we can connect to over the API > where the connections are over SSL with signed certificates, and so the > client will not need a client-cert for authenticated connections. > > So in that world, we would have similar behaviour: > > $ juju connect [email protected] fb5a2570-e6f2-11e3-ac10-0800200c9a66 > password: > local environment name [foo-production]: > > and the result would be a file > $JUJU_HOME/environments/foo-production.jenv > being written out with Eric's credentials. >
I'm +1 on pretty much all of this, but remember that in a world of multi-environment state servers you don't need, and probably don't want, a local .jenv at all. You need to be able to connect to and authenticate with a state server, sure; and so we'd need to store an address (and possibly a cert); but once you're connected you should be able to list your environments, and the users your identity allows you access to in those environments. .jenv distribution will remain necessary in certain circumstances (singular state servers), but if you and I have identities on the same state server I don't want to have to do *anything* other than `user add tim --identity lp:~thumper` (or whatever scheme we're using). I can then just tell you "hey dude, I gave you access to my environment", and probably don't even need to tell you the UUID [0]. If you look from far enough away there's no real difference between the situations, anyway. At the moment, your $JUJU_HOME/environments is an implicit authentication domain (gated only on your having read access to that directory); in the future, being able to authenticate as a particular identity gives you access to a similar domain on a state server. The user/environment pairs you have access to are determined on the fly according to what users/environments actually exist in the state server, rather than with files on disk; and there's no need to store an additional password there, because you're already verified on that state server and don't need to prove anything to a different remote machine; but in purpose and impact it's pretty much the same thing. Cheers William [0] There may be problems still to be solved re securely *identifying* that environment (could Alice maliciously give you access to her environment in the hope that you'll leak sensitive information into it, or implicate you in that environment's nefarious/embarrassing activity?) but this is really just another example of the same old tension between security and usability. We need to consider it and find a happy path, but it's a derail from this thread, I think.
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
