You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Kevin Kluge <Ke...@citrix.com> on 2012/05/01 06:01:14 UTC
RE: user credntials
I think Abhi's proposal would avoid all this, yes?
I am not sure if I like have a single parameter that can be either MD5 (as in 2.2.x) , either MD5 or plaintext (as in 3.0.x), or plaintext (as in some future release when MD5 has been deprecated). The alternative is to just introduce a new parameter (for cleartext password), and exactly one of that new param or the existing param must be specified.
> -----Original Message-----
> From: Will Chan [mailto:will.chan@citrix.com]
> Sent: Monday, April 30, 2012 11:21 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: user credntials
>
> I also want to point out that this is simply the default behavior for a brand
> new CS install and as Chiradeep pointed out, it only applies to the session-
> based login that requires a username/password.
>
> We should not be changing this behavior by default on an upgrade because
> some people may just use this as-is with zero modification. If there are CS
> admins that want to change this behavior, they would have had to do one or
> more of the following:
>
> - Create their own custom Auth adapter
> - Modification of components.xml to configure this
> - Perhaps customizing the UI to pass in the password whether hashed or not.
>
> For the people that have gone about this way, after a CS update, there
> should be no need to change anything other than perhaps the UI as their
> existing adapter and components XML should refer to their customer
> adapters.
>
> Will
>
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Monday, April 30, 2012 10:06 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: user credntials
>
> Just wanted to point out this only affects the session-based logins via the
> GUI (although one can script this kind of API interaction as well).
> API-key-based authentication continues as before.
>
> On 4/30/12 9:15 AM, "Abhinandan Prateek"
> <Ab...@citrix.com>
> wrote:
>
> >The deprecation of MD5 can be done in a graceful fashion with the
> >following scheme:
> >
> >We add a Authenticator which can take plaintext password and add it
> >after the MD5 authenticator. Anyone who is already using the MD5
> >password in API will continue to function as they are now.
> >Anyone upgrading is not affected.
> >
> >Any new integrator/cloudstack user can start using plaintext password
> >in API without issues, as there is a plaintext authenticator in the chain.
> >Again the use of SSL ensures channel security and keeps the password
> >safe as is done by countless other websites taking plaintext passwords
> >from the users.
> >
> >With plaintext passwords cloudstack can now seamlessly work with
> >external authentication systems as well. With this we do not need a new
> >parameter too, probably a warning in the logs saying that this is
> >going to be deprecated soon.
> >
> >-Abhi
> >
> >-----Original Message-----
> >From: Kevin Kluge [mailto:Kevin.Kluge@citrix.com]
> >Sent: Monday, April 30, 2012 9:30 PM
> >To: Will Chan; cloudstack-dev@incubator.apache.org
> >Subject: RE: user credntials
> >
> >This means the client has to figure out whether to send MD5 hash or
> >cleartext on a per-cloud basis. That seems unreasonable.
> >
> >Why don't we just send plain text passwords and expect the use of SSL?
> >We'd have to add a new parameter and deprecate the current MD5 hash
> >password.
> >
> >-kevin
> >
> >> -----Original Message-----
> >> From: Will Chan
> >> Sent: Saturday, April 28, 2012 4:39 PM
> >> To: cloudstack-dev@incubator.apache.org; Kevin Kluge
> >> Subject: RE: user credntials
> >>
> >> The service provider (or whomever is hosting CloudStack) needs to
> >> make that decision. Using the default CS installation, we default to
> >> the MD5UserAuthenticator which requires passwords passed to the login
> >> command to be MD5 hashed. This got changed to plain-text in 3.0 and
> >> must be reverted back to MD5 in 3.0.2 when the upgrade patch is
> >> released or anyone upgrading could get affected.
> >>
> >> If the service/hosting provider wants to use a different hashing
> >> algorithm -
> >> OR- none, he can create or configure CS to use that adapter.
> >> However, they are responsible for informing their customer.
> >>
> >> Will
> >>
> >> ________________________________________
> >> From: Abhinandan Prateek [Abhinandan.Prateek@citrix.com]
> >> Sent: Saturday, April 28, 2012 3:28 PM
> >> To: Kevin Kluge; cloudstack-dev@incubator.apache.org
> >> Subject: RE: user credntials
> >>
> >> The use of plaintext passwords in API is required for only those
> >> cloudstack users who wish to use an external authentication mechanism
> >> and will be documented.
> >> The support for the encoded password has to be kept as is due to
> >> existing users of cloudstack.
> >>
> >>
> >> -----Original Message-----
> >> From: Kevin Kluge
> >> Sent: Sunday, April 29, 2012 1:09 AM
> >> To: Abhinandan Prateek; cloudstack-dev@incubator.apache.org
> >> Subject: RE: user credntials
> >>
> >> How would an API client know to use cleartext or MD5 hash?
> >>
> >>
> >> > -----Original Message-----
> >> > From: Abhinandan Prateek
> >> > Sent: Saturday, April 28, 2012 7:56 AM
> >> > To: Kevin Kluge; cloudstack-dev@incubator.apache.org
> >> > Subject: RE: user credntials
> >> >
> >> > In 2.2.* we were passing MD5 encoded password via UI. For Acton it
> >> > changed to unencrypted password as that was the only way to have
> >> > external systems to authenticate cloudstack users for example
> >> > external
> >> LDAP.
> >> > This is being reverted back to MD5 encoded password in 3.0.2 as it
> >> > was. It will be left to the admin to configure this encryption
> >> > mechanism in case LDAP is in use.
> >> >
> >> > -Abhi
> >> >
> >> > -----Original Message-----
> >> > From: Kevin Kluge
> >> > Sent: Saturday, April 28, 2012 8:16 PM
> >> > To: Abhinandan Prateek; cloudstack-dev@incubator.apache.org
> >> > Subject: RE: user credntials
> >> >
> >> > Abhi, is this a backwards incompatible API change? Also, what does
> >>it
> >> mean
> >> > for upgrade?
> >> >
> >> > I thought we always sent MD5 hashed passwords from UI to MS. Can
> >> > you explain the change a bit more?
> >> >
> >> > -kevin
> >> >
> >> > > -----Original Message-----
> >> > > From: Abhinandan Prateek
> >> > > Sent: Saturday, April 28, 2012 12:14 AM
> >> > > Subject: user credntials
> >> > >
> >> > > Team,
> >> > > There has been a change in the way passwords are being passed
> >> > > from the cloudstack UI. In case you have difficulty login with
> >> > > the new 3.* build, clear your browser cache. If you are using API
> >> > > to login then you need to provide
> >> > > MD5 encrypted passwords to login instead of plaintext. In case
> >> > > you still have issues drop me an email.
> >> > > -Abhi
RE: user credntials
Posted by Abhinandan Prateek <Ab...@citrix.com>.
We need to transition to plaintext password, any encoding for the internal or third party authentication system will happen in the adapter. To transition we will have an additional parameter in the auth API so that it can be clearly documented and does not confuse or break the existing cloudstack user who have been passing MD5 encoded strings. This way we have same interface for external and internal auth and can also chain authentication adapters.
-Abhi
-----Original Message-----
From: Will Chan [mailto:will.chan@citrix.com]
Sent: Tuesday, May 01, 2012 9:42 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: user credntials
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
________________________________________
From: Kevin Kluge [Kevin.Kluge@citrix.com]
Sent: Monday, April 30, 2012 9:01 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: user credntials
I think Abhi's proposal would avoid all this, yes?
I am not sure if I like have a single parameter that can be either MD5 (as in 2.2.x) , either MD5 or plaintext (as in 3.0.x), or plaintext (as in some future release when MD5 has been deprecated). The alternative is to just introduce a new parameter (for cleartext password), and exactly one of that new param or the existing param must be specified.
> -----Original Message-----
> From: Will Chan [mailto:will.chan@citrix.com]
> Sent: Monday, April 30, 2012 11:21 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: user credntials
>
> I also want to point out that this is simply the default behavior for
> a brand new CS install and as Chiradeep pointed out, it only applies
> to the session- based login that requires a username/password.
>
> We should not be changing this behavior by default on an upgrade
> because some people may just use this as-is with zero modification.
> If there are CS admins that want to change this behavior, they would
> have had to do one or more of the following:
>
> - Create their own custom Auth adapter
> - Modification of components.xml to configure this
> - Perhaps customizing the UI to pass in the password whether hashed or not.
>
> For the people that have gone about this way, after a CS update,
> there should be no need to change anything other than perhaps the UI
> as their existing adapter and components XML should refer to their
> customer adapters.
>
> Will
>
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Monday, April 30, 2012 10:06 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: user credntials
>
> Just wanted to point out this only affects the session-based logins
> via the GUI (although one can script this kind of API interaction as well).
> API-key-based authentication continues as before.
>
> On 4/30/12 9:15 AM, "Abhinandan Prateek"
> <Ab...@citrix.com>
> wrote:
>
> >The deprecation of MD5 can be done in a graceful fashion with the
> >following scheme:
> >
> >We add a Authenticator which can take plaintext password and add it
> >after the MD5 authenticator. Anyone who is already using the MD5
> >password in API will continue to function as they are now.
> >Anyone upgrading is not affected.
> >
> >Any new integrator/cloudstack user can start using plaintext password
> >in API without issues, as there is a plaintext authenticator in the chain.
> >Again the use of SSL ensures channel security and keeps the password
> >safe as is done by countless other websites taking plaintext
> >passwords from the users.
> >
> >With plaintext passwords cloudstack can now seamlessly work with
> >external authentication systems as well. With this we do not need a
> >new parameter too, probably a warning in the logs saying that this
> >is going to be deprecated soon.
> >
> >-Abhi
> >
> >-----Original Message-----
> >From: Kevin Kluge [mailto:Kevin.Kluge@citrix.com]
> >Sent: Monday, April 30, 2012 9:30 PM
> >To: Will Chan; cloudstack-dev@incubator.apache.org
> >Subject: RE: user credntials
> >
> >This means the client has to figure out whether to send MD5 hash or
> >cleartext on a per-cloud basis. That seems unreasonable.
> >
> >Why don't we just send plain text passwords and expect the use of SSL?
> >We'd have to add a new parameter and deprecate the current MD5 hash
> >password.
> >
> >-kevin
> >
> >> -----Original Message-----
> >> From: Will Chan
> >> Sent: Saturday, April 28, 2012 4:39 PM
> >> To: cloudstack-dev@incubator.apache.org; Kevin Kluge
> >> Subject: RE: user credntials
> >>
> >> The service provider (or whomever is hosting CloudStack) needs to
> >> make that decision. Using the default CS installation, we default
> >> to the MD5UserAuthenticator which requires passwords passed to the
> >> login command to be MD5 hashed. This got changed to plain-text in
> >> 3.0 and must be reverted back to MD5 in 3.0.2 when the upgrade
> >> patch is released or anyone upgrading could get affected.
> >>
> >> If the service/hosting provider wants to use a different hashing
> >> algorithm -
> >> OR- none, he can create or configure CS to use that adapter.
> >> However, they are responsible for informing their customer.
> >>
> >> Will
> >>
> >> ________________________________________
> >> From: Abhinandan Prateek [Abhinandan.Prateek@citrix.com]
> >> Sent: Saturday, April 28, 2012 3:28 PM
> >> To: Kevin Kluge; cloudstack-dev@incubator.apache.org
> >> Subject: RE: user credntials
> >>
> >> The use of plaintext passwords in API is required for only those
> >> cloudstack users who wish to use an external authentication
> >> mechanism and will be documented.
> >> The support for the encoded password has to be kept as is due to
> >> existing users of cloudstack.
> >>
> >>
> >> -----Original Message-----
> >> From: Kevin Kluge
> >> Sent: Sunday, April 29, 2012 1:09 AM
> >> To: Abhinandan Prateek; cloudstack-dev@incubator.apache.org
> >> Subject: RE: user credntials
> >>
> >> How would an API client know to use cleartext or MD5 hash?
> >>
> >>
> >> > -----Original Message-----
> >> > From: Abhinandan Prateek
> >> > Sent: Saturday, April 28, 2012 7:56 AM
> >> > To: Kevin Kluge; cloudstack-dev@incubator.apache.org
> >> > Subject: RE: user credntials
> >> >
> >> > In 2.2.* we were passing MD5 encoded password via UI. For Acton
> >> > it changed to unencrypted password as that was the only way to
> >> > have external systems to authenticate cloudstack users for
> >> > example external
> >> LDAP.
> >> > This is being reverted back to MD5 encoded password in 3.0.2 as
> >> > it was. It will be left to the admin to configure this encryption
> >> > mechanism in case LDAP is in use.
> >> >
> >> > -Abhi
> >> >
> >> > -----Original Message-----
> >> > From: Kevin Kluge
> >> > Sent: Saturday, April 28, 2012 8:16 PM
> >> > To: Abhinandan Prateek; cloudstack-dev@incubator.apache.org
> >> > Subject: RE: user credntials
> >> >
> >> > Abhi, is this a backwards incompatible API change? Also, what does
> >>it
> >> mean
> >> > for upgrade?
> >> >
> >> > I thought we always sent MD5 hashed passwords from UI to MS. Can
> >> > you explain the change a bit more?
> >> >
> >> > -kevin
> >> >
> >> > > -----Original Message-----
> >> > > From: Abhinandan Prateek
> >> > > Sent: Saturday, April 28, 2012 12:14 AM
> >> > > Subject: user credntials
> >> > >
> >> > > Team,
> >> > > There has been a change in the way passwords are being
> >> > > passed from the cloudstack UI. In case you have difficulty
> >> > > login with the new 3.* build, clear your browser cache. If you
> >> > > are using API to login then you need to provide
> >> > > MD5 encrypted passwords to login instead of plaintext. In case
> >> > > you still have issues drop me an email.
> >> > > -Abhi
RE: user credntials
Posted by Will Chan <wi...@citrix.com>.
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.Kluge@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.chan@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 [david@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 <wi...@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
RE: user credntials
Posted by Kevin Kluge <Ke...@citrix.com>.
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.chan@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 [david@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 <wi...@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
RE: user credntials
Posted by Will Chan <wi...@citrix.com>.
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 [david@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 <wi...@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
Re: user credntials
Posted by David Nalley <da...@gnsa.us>.
On Apr 30, 2012, at 9:11 PM, Will Chan <wi...@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
RE: user credntials
Posted by Will Chan <wi...@citrix.com>.
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
________________________________________
From: Kevin Kluge [Kevin.Kluge@citrix.com]
Sent: Monday, April 30, 2012 9:01 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: user credntials
I think Abhi's proposal would avoid all this, yes?
I am not sure if I like have a single parameter that can be either MD5 (as in 2.2.x) , either MD5 or plaintext (as in 3.0.x), or plaintext (as in some future release when MD5 has been deprecated). The alternative is to just introduce a new parameter (for cleartext password), and exactly one of that new param or the existing param must be specified.
> -----Original Message-----
> From: Will Chan [mailto:will.chan@citrix.com]
> Sent: Monday, April 30, 2012 11:21 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: user credntials
>
> I also want to point out that this is simply the default behavior for a brand
> new CS install and as Chiradeep pointed out, it only applies to the session-
> based login that requires a username/password.
>
> We should not be changing this behavior by default on an upgrade because
> some people may just use this as-is with zero modification. If there are CS
> admins that want to change this behavior, they would have had to do one or
> more of the following:
>
> - Create their own custom Auth adapter
> - Modification of components.xml to configure this
> - Perhaps customizing the UI to pass in the password whether hashed or not.
>
> For the people that have gone about this way, after a CS update, there
> should be no need to change anything other than perhaps the UI as their
> existing adapter and components XML should refer to their customer
> adapters.
>
> Will
>
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Monday, April 30, 2012 10:06 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: user credntials
>
> Just wanted to point out this only affects the session-based logins via the
> GUI (although one can script this kind of API interaction as well).
> API-key-based authentication continues as before.
>
> On 4/30/12 9:15 AM, "Abhinandan Prateek"
> <Ab...@citrix.com>
> wrote:
>
> >The deprecation of MD5 can be done in a graceful fashion with the
> >following scheme:
> >
> >We add a Authenticator which can take plaintext password and add it
> >after the MD5 authenticator. Anyone who is already using the MD5
> >password in API will continue to function as they are now.
> >Anyone upgrading is not affected.
> >
> >Any new integrator/cloudstack user can start using plaintext password
> >in API without issues, as there is a plaintext authenticator in the chain.
> >Again the use of SSL ensures channel security and keeps the password
> >safe as is done by countless other websites taking plaintext passwords
> >from the users.
> >
> >With plaintext passwords cloudstack can now seamlessly work with
> >external authentication systems as well. With this we do not need a new
> >parameter too, probably a warning in the logs saying that this is
> >going to be deprecated soon.
> >
> >-Abhi
> >
> >-----Original Message-----
> >From: Kevin Kluge [mailto:Kevin.Kluge@citrix.com]
> >Sent: Monday, April 30, 2012 9:30 PM
> >To: Will Chan; cloudstack-dev@incubator.apache.org
> >Subject: RE: user credntials
> >
> >This means the client has to figure out whether to send MD5 hash or
> >cleartext on a per-cloud basis. That seems unreasonable.
> >
> >Why don't we just send plain text passwords and expect the use of SSL?
> >We'd have to add a new parameter and deprecate the current MD5 hash
> >password.
> >
> >-kevin
> >
> >> -----Original Message-----
> >> From: Will Chan
> >> Sent: Saturday, April 28, 2012 4:39 PM
> >> To: cloudstack-dev@incubator.apache.org; Kevin Kluge
> >> Subject: RE: user credntials
> >>
> >> The service provider (or whomever is hosting CloudStack) needs to
> >> make that decision. Using the default CS installation, we default to
> >> the MD5UserAuthenticator which requires passwords passed to the login
> >> command to be MD5 hashed. This got changed to plain-text in 3.0 and
> >> must be reverted back to MD5 in 3.0.2 when the upgrade patch is
> >> released or anyone upgrading could get affected.
> >>
> >> If the service/hosting provider wants to use a different hashing
> >> algorithm -
> >> OR- none, he can create or configure CS to use that adapter.
> >> However, they are responsible for informing their customer.
> >>
> >> Will
> >>
> >> ________________________________________
> >> From: Abhinandan Prateek [Abhinandan.Prateek@citrix.com]
> >> Sent: Saturday, April 28, 2012 3:28 PM
> >> To: Kevin Kluge; cloudstack-dev@incubator.apache.org
> >> Subject: RE: user credntials
> >>
> >> The use of plaintext passwords in API is required for only those
> >> cloudstack users who wish to use an external authentication mechanism
> >> and will be documented.
> >> The support for the encoded password has to be kept as is due to
> >> existing users of cloudstack.
> >>
> >>
> >> -----Original Message-----
> >> From: Kevin Kluge
> >> Sent: Sunday, April 29, 2012 1:09 AM
> >> To: Abhinandan Prateek; cloudstack-dev@incubator.apache.org
> >> Subject: RE: user credntials
> >>
> >> How would an API client know to use cleartext or MD5 hash?
> >>
> >>
> >> > -----Original Message-----
> >> > From: Abhinandan Prateek
> >> > Sent: Saturday, April 28, 2012 7:56 AM
> >> > To: Kevin Kluge; cloudstack-dev@incubator.apache.org
> >> > Subject: RE: user credntials
> >> >
> >> > In 2.2.* we were passing MD5 encoded password via UI. For Acton it
> >> > changed to unencrypted password as that was the only way to have
> >> > external systems to authenticate cloudstack users for example
> >> > external
> >> LDAP.
> >> > This is being reverted back to MD5 encoded password in 3.0.2 as it
> >> > was. It will be left to the admin to configure this encryption
> >> > mechanism in case LDAP is in use.
> >> >
> >> > -Abhi
> >> >
> >> > -----Original Message-----
> >> > From: Kevin Kluge
> >> > Sent: Saturday, April 28, 2012 8:16 PM
> >> > To: Abhinandan Prateek; cloudstack-dev@incubator.apache.org
> >> > Subject: RE: user credntials
> >> >
> >> > Abhi, is this a backwards incompatible API change? Also, what does
> >>it
> >> mean
> >> > for upgrade?
> >> >
> >> > I thought we always sent MD5 hashed passwords from UI to MS. Can
> >> > you explain the change a bit more?
> >> >
> >> > -kevin
> >> >
> >> > > -----Original Message-----
> >> > > From: Abhinandan Prateek
> >> > > Sent: Saturday, April 28, 2012 12:14 AM
> >> > > Subject: user credntials
> >> > >
> >> > > Team,
> >> > > There has been a change in the way passwords are being passed
> >> > > from the cloudstack UI. In case you have difficulty login with
> >> > > the new 3.* build, clear your browser cache. If you are using API
> >> > > to login then you need to provide
> >> > > MD5 encrypted passwords to login instead of plaintext. In case
> >> > > you still have issues drop me an email.
> >> > > -Abhi