Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: user credntials
References: 
 <64FB1554ABC9B44FAA773FBD6CB889C2F915DFC375@BANPMAILBOX01.citrite.net>
 <CBC41430.1F6C2%chiradeep.vittal@citrix.com>
 <61AE1E2837A06D4A8E98B796183842D40116B82ACB35@SJCPMAILBOX01.citrite.net>
 <61AE1E2837A06D4A8E98B796183842D40116B82ACCE9@SJCPMAILBOX01.citrite.net>
 <61AE1E2837A06D4A8E98B796183842D40116B804A245@SJCPMAILBOX01.citrite.net>
From: David Nalley <david@gnsa.us>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: 
 <61AE1E2837A06D4A8E98B796183842D40116B804A245@SJCPMAILBOX01.citrite.net>
Message-Id: <92DD066A-75FA-4A29-A939-13363DA7B4F5@gnsa.us>
Date: Mon, 30 Apr 2012 21:35:19 -0700
To: "cloudstack-dev@incubator.apache.org"
 <cloudstack-dev@incubator.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)


On Apr 30, 2012, at 9:11 PM, Will Chan <will.chan@citrix.com> wrote:

> The parameter for password is simply just used to pass information from th=
e 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 p=
assed in, the default adapter is just doing a simple comparison againt the D=
B.  If suddenly the admin wishes to use the LDAPAuthenticator, he should req=
uire 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 als=
o imagine someone wanting SHA-256, etc. for their password encryption.  The o=
nly 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 reall=
y doubt this would ever be used.  It would mean two different auth DB.
>=20
> Will
>=20
> ________________________________________
>=20
So let me point out a practical example where this fails. Cumulus, the andro=
id client to CloudStack, the login command to get a token and use session ba=
sed 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 a=
n external service. They take in username and password from the user, do the=
y md5 the password or not? How can they tell what they should be passing? (s=
ame 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.=20

--David=