I am not disagreeing with the idea that anyone that is creating an app using our session-based auth would be "broken" due to the fact they may not be able to pass in the correct password format. My point is that we support a flexible authentication scheme which allows the cloud operator or enterprise to switch out to an auth scheme of their choice. The only way to standardize on this would be to force everyone to accept a clear-text password (or whatever format it may be, but it cannot change). This may not be their preference.
My suggestion for app developers that want to create something that is compatible across all clouds (powered by CloudStack) would be to use the api key auth scheme. Or, perhaps someone from the community who's done or seen this before can give a better recommendation. Will -----Original Message----- From: Kevin Kluge [mailto:kevin.kl...@citrix.com] Sent: Wednesday, May 02, 2012 10:08 AM To: cloudstack-dev@incubator.apache.org Subject: RE: user credntials Will, I think Abhi and David and I are all in sync -- telling people that they need to know how a given cloud is taking passwords is really broken. I can't think of any precedent for this in any other software I've seen with pluggable auth backends. If I were a client developer and faced with this API I would immediately ask how I'm supposed to know what to do, and likely make a post to the list expressing how strange and annoying it is. I get the sense that you think only the CS developers need to know this but we have many examples of applications that have written to the login API already and judging by all the interest post-Apache-announcement I'm sure more are coming. Maybe you are right that API keys are preferable but I don't think we can use that as an excuse for a fundamentally broken API. Can you agree that we have to transition to cleartext exclusively? -kevin > -----Original Message----- > From: Will Chan [mailto:will.c...@citrix.com] > Sent: Monday, April 30, 2012 10:08 PM > To: cloudstack-dev@incubator.apache.org > Subject: RE: user credntials > > In your example, they would need to know how the cloud is accepting > the password. Perhaps, they can give multiple options. It's not an > easy way to solve but multiple parameters is not going to solve this > solution because (1) there may be other ways to pass in the password > and (2) I suppose they could just send it via all possible parameters but > that's not very practical. > > The session-based login is primarily used for easier UI development. > In all other clients like android, it may make more sense to use the API keys. > > Will > > ________________________________________ > From: David Nalley [da...@gnsa.us] > Sent: Monday, April 30, 2012 9:35 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: user credntials > > On Apr 30, 2012, at 9:11 PM, Will Chan <will.c...@citrix.com> wrote: > > > The parameter for password is simply just used to pass information > > from > the client to CS. It's really up to the AuthenticatorAdapter to > decide how it should use the parameter. Since by default, MD5 hashed > password is being passed in, the default adapter is just doing a > simple comparison againt the DB. If suddenly the admin wishes to use > the LDAPAuthenticator, he should require that the password to be in > plain-text (assuming that is what is used to compare against). We > don't need need two parameters for this. You can also imagine someone > wanting SHA-256, etc. for their password encryption. > The only way I can think having two separate parameters is if there is > a use- case for using multiple adapters, each requiring their own > parameter but I really doubt this would ever be used. It would mean two > different auth DB. > > > > Will > > > > ________________________________________ > > > So let me point out a practical example where this fails. Cumulus, the > android client to CloudStack, the login command to get a token and use > session based auth initially. The endpoint could be any CloudStack > deployment, and the end user may not know whether or not the operator > is using native auth or an external service. They take in username and > password from the user, do they md5 the password or not? How can they > tell what they should be passing? (same problem with multiple > parameters unless we accept all and only use one). And there are > plenty of possible apps that would behave in this manner. > > --David
