I know it's probably an implementation detail, but always better to consider security sooner rather than later.
Also, given that security is one way that cloud vendors differ, it's something we should bake into the API correctly the first time through.
And yet also, given the desire for stateless drivers where possible, it may affect our security decisions, depending on how we define "stateless" or "security".
Three main models if security seen by me thus far are:
a) Some login() type of call, which takes a name and a password. Many times the "password" is not your personal password associated with web-console logins, but another, randomly-generated (hah!) key that you can use for just API calls. The API key can be regenerated if it's been compromised, without affecting your web-UI login credentials. This login() returns a session token which is then passed through to every other call. This is basically normal web workflow with session ID in query string or a cookie, but with a separate password.
b) no login(), but an API key passed with each request. The ultimate service has no concept of sessions.
c) no login(), but each request is cryptographically signed. Once again, no concept of sessions.
Does our desire for stateless drivers also include a desire to have no session state? Or would that be an acceptable level of state the implementor of the API needs to concern himself with?
If we insist on no sessions, and we're using, let's say, the adapter that talks EC2 signed SOAP out the backside, how do we communicate our EC2 credentials to the libcloud receiver? If we're doing credential mapping, then I can login to the proxy as "bob", and it's already in possession of my EC2 X.509 credentials, provided through some out-of- band method (ie, a portal).
But, if I'm using the driver directly, on port 80, over REST... Do we still insist on the driver having a store of credentials local to it? Or would the client be expected to ship his X.509 certificate to the driver with every request, so that the driver can sign the ultimate EC2 SOAP requests on his behalf?
If we allow/require stateful sessions, then at least login(...) could take a driver-specific hash of information to set up the security context.
ie:
login ( :x509_cert=>'.....', :access_key=>'...', :secret_access_key=>'....' )
for the EC2 driver, which would expect those 3 members.
Yes, login() would actually be a PUT to /sessions, and be RESTful...
But basically, leave the schema for the Session resource as void*, or implementation-defined, to allow for flexibility.
For name/password, login( :name=>'...', :password=>'...'), and for API key-based, just login( :key=>'...' ) or such.
So, is session state too much state? I think it'd be okay to store in RAM, no guarantee on longevity, and requires no local long-term storage.
Thanks,
-Bob
Bob McWhirter wrote:
I know it's probably an implementation detail, but always better to consider security sooner rather than later.
Also, given that security is one way that cloud vendors differ, it's something we should bake into the API correctly the first time through.
And yet also, given the desire for stateless drivers where possible, it may affect our security decisions, depending on how we define "stateless" or "security".
Three main models if security seen by me thus far are:
a) Some login() type of call, which takes a name and a password.Many times the "password" is not your personal password associated with web-console logins, but another, randomly-generated (hah!) key that you can use for just API calls. The API key can be regenerated if it's been compromised, without affecting your web-UI login credentials. This login() returns a session token which is then passed through to every other call. This is basically normal web workflow with session ID in query string or a cookie, but with a separate password.
b) no login(), but an API key passed with each request. Theultimate service has no concept of sessions.
c) no login(), but each request is cryptographically signed. Onceagain, no concept of sessions.
Does our desire for stateless drivers also include a desire to have no session state? Or would that be an acceptable level of state the implementor of the API needs to concern himself with?
If our goal is to cross many APIs, I believe libvirtd (or the drivers in it) will need the notion of a session. That way it can locate my credentials and do the transformation.
If we insist on no sessions, and we're using, let's say, the adapter that talks EC2 signed SOAP out the backside, how do we communicate our EC2 credentials to the libcloud receiver? If we're doing credential mapping, then I can login to the proxy as "bob", and it's already in possession of my EC2 X.509 credentials, provided through some out-of-band method (ie, a portal).
But, if I'm using the driver directly, on port 80, over REST... Do we still insist on the driver having a store of credentials local to it? Or would the client be expected to ship his X.509 certificate to the driver with every request, so that the driver can sign the ultimate EC2 SOAP requests on his behalf?
I have assumed that the call between client->libvirtd would be different from libvirtd->driver (REST on the former, some internal AST on the latter). If that is the case, the client would need to use some frontend to do REST->AST, and therefore the use should be the same as if not local.
If we allow/require stateful sessions, then at least login(...) could take a driver-specific hash of information to set up the security context.
ie:
login( :x509_cert=>'.....', :access_key=>'...',:secret_access_key=>'....' )
for the EC2 driver, which would expect those 3 members.
Yes, login() would actually be a PUT to /sessions, and be RESTful...
But basically, leave the schema for the Session resource as void*, or implementation-defined, to allow for flexibility.
For name/password, login( :name=>'...', :password=>'...'), and for API key-based, just login( :key=>'...' ) or such.
So, is session state too much state? I think it'd be okay to store in RAM, no guarantee on longevity, and requires no local long-term storage.
No.. it is fine.
-- bk
On Tue, Jul 14, 2009 at 07:16:12AM -0400, Bryan Kearney wrote:
Bob McWhirter wrote:
I know it's probably an implementation detail, but always better to consider security sooner rather than later.
Also, given that security is one way that cloud vendors differ, it's something we should bake into the API correctly the first time through.
And yet also, given the desire for stateless drivers where possible, it may affect our security decisions, depending on how we define "stateless" or "security".
Three main models if security seen by me thus far are:
a) Some login() type of call, which takes a name and a password. Many times the "password" is not your personal password associated with web-console logins, but another, randomly-generated (hah!) key that you can use for just API calls. The API key can be regenerated if it's been compromised, without affecting your web-UI login credentials. This login() returns a session token which is then passed through to every other call. This is basically normal web workflow with session ID in query string or a cookie, but with a separate password.
b) no login(), but an API key passed with each request. The ultimate service has no concept of sessions.
c) no login(), but each request is cryptographically signed. Once again, no concept of sessions.
Does our desire for stateless drivers also include a desire to have no session state? Or would that be an acceptable level of state the implementor of the API needs to concern himself with?
If our goal is to cross many APIs, I believe libvirtd (or the drivers in it) will need the notion of a session. That way it can locate my credentials and do the transformation.
If we insist on no sessions, and we're using, let's say, the adapter that talks EC2 signed SOAP out the backside, how do we communicate our EC2 credentials to the libcloud receiver? If we're doing credential mapping, then I can login to the proxy as "bob", and it's already in possession of my EC2 X.509 credentials, provided through some out-of-band method (ie, a portal).
But, if I'm using the driver directly, on port 80, over REST... Do we still insist on the driver having a store of credentials local to it? Or would the client be expected to ship his X.509 certificate to the driver with every request, so that the driver can sign the ultimate EC2 SOAP requests on his behalf?
I have assumed that the call between client->libvirtd would be different from libvirtd->driver (REST on the former, some internal AST on the latter). If that is the case, the client would need to use some frontend to do REST->AST, and therefore the use should be the same as if not local.
If we allow/require stateful sessions, then at least login(...) could take a driver-specific hash of information to set up the security context.
ie:
login( :x509_cert=>'.....', :access_key=>'...', :secret_access_key=>'....' )
for the EC2 driver, which would expect those 3 members.
Yes, login() would actually be a PUT to /sessions, and be RESTful...
But basically, leave the schema for the Session resource as void*, or implementation-defined, to allow for flexibility.
For name/password, login( :name=>'...', :password=>'...'), and for API key-based, just login( :key=>'...' ) or such.
So, is session state too much state? I think it'd be okay to store in RAM, no guarantee on longevity, and requires no local long-term storage.
No.. it is fine.
-- bk
My naive inclination would be to have the various libcloud adapters be completely stateless and *not* support sessions -- i.e. pass the key on every call. This is going to make them easier to talk through from e.g. the proxy. I'm willing to be talked out of this though if someone has a better idea.
--H
Although cookies aren't really RESTful, they're damn useful in the Web precisely because of sessions. You can still provide a session concept without them, but it requires a bit more work.
I'd vote for session support.
http://www.w3.org/2007/01/wos-papers/redhat
Mark.
On 14 Jul 2009, at 05:44, Bob McWhirter wrote:
I know it's probably an implementation detail, but always better to consider security sooner rather than later.
Also, given that security is one way that cloud vendors differ, it's something we should bake into the API correctly the first time through.
And yet also, given the desire for stateless drivers where possible, it may affect our security decisions, depending on how we define "stateless" or "security".
Three main models if security seen by me thus far are:
a) Some login() type of call, which takes a name and a password. Many times the "password" is not your personal password associated with web-console logins, but another, randomly-generated (hah!) key that you can use for just API calls. The API key can be regenerated if it's been compromised, without affecting your web-UI login credentials. This login() returns a session token which is then passed through to every other call. This is basically normal web workflow with session ID in query string or a cookie, but with a separate password.
b) no login(), but an API key passed with each request. The ultimate service has no concept of sessions.
c) no login(), but each request is cryptographically signed. Once again, no concept of sessions.
Does our desire for stateless drivers also include a desire to have no session state? Or would that be an acceptable level of state the implementor of the API needs to concern himself with?
If we insist on no sessions, and we're using, let's say, the adapter that talks EC2 signed SOAP out the backside, how do we communicate our EC2 credentials to the libcloud receiver? If we're doing credential mapping, then I can login to the proxy as "bob", and it's already in possession of my EC2 X.509 credentials, provided through some out-of-band method (ie, a portal).
But, if I'm using the driver directly, on port 80, over REST... Do we still insist on the driver having a store of credentials local to it? Or would the client be expected to ship his X.509 certificate to the driver with every request, so that the driver can sign the ultimate EC2 SOAP requests on his behalf?
If we allow/require stateful sessions, then at least login(...) could take a driver-specific hash of information to set up the security context.
ie:
login ( :x509_cert =>'.....', :access_key=>'...', :secret_access_key=>'....' )
for the EC2 driver, which would expect those 3 members.
Yes, login() would actually be a PUT to /sessions, and be RESTful...
But basically, leave the schema for the Session resource as void*, or implementation-defined, to allow for flexibility.
For name/password, login( :name=>'...', :password=>'...'), and for API key-based, just login( :key=>'...' ) or such.
So, is session state too much state? I think it'd be okay to store in RAM, no guarantee on longevity, and requires no local long-term storage.
Thanks,
-Bob
Libcloud-list mailing list Libcloud-list@redhat.com https://www.redhat.com/mailman/listinfo/libcloud-list
--- Mark Little mlittle@redhat.com
JBoss, by Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
On Tue, 2009-07-14 at 00:44 -0400, Bob McWhirter wrote:
So, is session state too much state? I think it'd be okay to store in RAM, no guarantee on longevity, and requires no local long-term storage.
From an ease-of-use POV, it would be much nicer if libcloud had a
concept of session, and with that enough state to store credentials for each backend.
For a service that exposes the libcloud API though that storage must be persistent, and not just in memory: otherwise users of the API will get very strange errors when the service is restarted in the middle of one of their sessions. Basically, they'd have to expect a 'sorry, forgot your credentials' error on every API call, and then login again and redo the call.
I think though that the storage could be simple files in /var/lib or similar (or a simple sqlite database) by default.
David
From an ease-of-use POV, it would be much nicer if libcloud had a concept of session, and with that enough state to store credentials for each backend.
Yah, I think I agree on that. I'm working on a write-up about sessions and auth, again.
For a service that exposes the libcloud API though that storage must be persistent, and not just in memory: otherwise users of the API will get very strange errors when the service is restarted in the middle of one of their sessions. Basically, they'd have to expect a 'sorry, forgot your credentials' error on every API call, and then login again and redo the call.
I think they have to expect *some error* is possible at any time. It might be a 404 Not Found while the service is actually restarting, even if the service does maintain a persistent store of sessions. I think this QoS is more a function of an implementation. You could use ∂-API services without persistence, as long as you're aware of it.
-Bob
On Wed, 2009-07-15 at 09:44 -0400, Bob McWhirter wrote:
For a service that exposes the libcloud API though that storage must be persistent, and not just in memory: otherwise users of the API will get very strange errors when the service is restarted in the middle of one of their sessions. Basically, they'd have to expect a 'sorry, forgot your credentials' error on every API call, and then login again and redo the call.
I think they have to expect *some error* is possible at any time. It might be a 404 Not Found while the service is actually restarting, even if the service does maintain a persistent store of sessions. I think this QoS is more a function of an implementation. You could use ∂-API services without persistence, as long as you're aware of it.
It's not so much what happens while the server restarts - it's that after a restart each user will have an invalid session, so the window of failure is much much bigger.
The only failures (barring bugs) that users should have to worry about are network connectivity problems, which can be resolved by retrying the request - forgetting the credentials is different in that the user needs to login again.
David
A +1 on durability, but a -1 on assuming it can't be in a high- availability in-memory cache.
Mark.
On 15 Jul 2009, at 01:29, David Lutterkort wrote:
On Tue, 2009-07-14 at 00:44 -0400, Bob McWhirter wrote:
So, is session state too much state? I think it'd be okay to store in RAM, no guarantee on longevity, and requires no local long-term storage.
From an ease-of-use POV, it would be much nicer if libcloud had a
concept of session, and with that enough state to store credentials for each backend.
For a service that exposes the libcloud API though that storage must be persistent, and not just in memory: otherwise users of the API will get very strange errors when the service is restarted in the middle of one of their sessions. Basically, they'd have to expect a 'sorry, forgot your credentials' error on every API call, and then login again and redo the call.
I think though that the storage could be simple files in /var/lib or similar (or a simple sqlite database) by default.
David
Libcloud-list mailing list Libcloud-list@redhat.com https://www.redhat.com/mailman/listinfo/libcloud-list
--- Mark Little mlittle@redhat.com
JBoss, by Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
deltacloud-devel@lists.fedorahosted.org
-
Bob McWhirter -
Bryan Kearney -
David Lutterkort -
Hugh O. Brock -
Mark Little