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