Vijay, I have opened that Doc bug for you, and added you to the bug as a Watcher.
https://issues.apache.org/jira/browse/CLOUDSTACK-1815 Jessica T. On Thu, Mar 21, 2013 at 1:27 AM, Vijayendra Bhamidipati < vijayendra.bhamidip...@citrix.com> wrote: > Hi Prasanna, > > True, as of now the mechanism isn't configurable via the UI. The rationale > was that the encoding and authentication choices are seldom changed once > put in place, and that it would be better to not expose this as a > configurable option via the UI. The list properties introduced must be > documented as part of a doc bug associated with this change - I'll log one > for this on jira if it isn't already there, we should have it documented in > the admin guide. > > Earlier the client was required to md5 hash the password and send it over > in applicable API calls, but since this was recently changed so that the > client is now expected to pass the clear text password (which would be best > passed using https and thus leveraging the encryption mechanism that the > SSL handshake chooses, to protect against on the wire snooping), a cipher > needn't be applied anymore on the client side, so it doesn't need to know > about an encoding mechanism or ordering. The api signing process will stay > the same since the signature generated would basically be determined by the > supplied secret/api key pair as long as the other parameters stay the > same.. the signing is independent of this change.. > > I didn't put in an API call to list the authenticators'/encoders' current > ordering given the above situation.. any idea of other uses of having APIs > to retrieve these two lists?? I can put them in if they'll be useful.. > > If adding a new adapter, these would be a few tests to carry out: > > 1. Keep the lists as is, and verify that encoding/authentication work as > expected. > 2. Add the new bean id of the new adapter to the lists. > 3. Make the new bean id the first in the encoder list, restart the mgmt > server, add a user, and verify by select password from cloud.user; for that > user, that the password was generated using this new encoding adapter. > 4. Next, if the same class implements both the encoder and authenticator, > put the same bean id anywhere in the authenticator list, and if a different > class implements the authenticator, put that new bean id in the > authenticator list, and restart the mgmt server. A login of the new user > should succeed eventually when it gets authenticated by the new adapter. > 5. Next, remove the bean from the authenticator list, restart the mgmt > server, and retry the user login, and it should fail. > > Regards, > Vijay > > ________________________________________ > From: srivatsav.prasa...@gmail.com [srivatsav.prasa...@gmail.com] On > Behalf Of prasanna [t...@apache.org] > Sent: Wednesday, March 20, 2013 10:09 PM > To: cloudstack-...@incubator.apache.org > Subject: Re: Review Request: Make SHA256Salt the default password encoding > and authentication mechanism for cloudstack > > On 20 March 2013 23:56, Vijayendra Bhamidipati > <vijayendra.bhamidip...@citrix.com> wrote: > > Hi Chip, Prasanna, > > > > Yes, the change is pretty straightforward, the reasoning is to make > default password encoding more secure because the SHA256salted > authenticator recently added by Hugo salts the passwords while the existing > MD5 authenticator doesn't, and is the default. This change gives the CS > admin the flexibility to choose the ordering of the > encoders/authenticators. No new authenticator/encoder classes needed to be > added, the existing ones are simply used better. > > > > Upgrade scenarios were considered and these changes will have no effect > on upgrades. Only new users and updated users will have their passwords > encoded by the first valid encoder in the UserPasswordEncoder list. > Existing users will still get authenticated as before since authentication > passes through all the authenticators available in the UserAuthenticator > list until one of them succeeds or all fail. > > > > Thanks Vijay, I'm just wondering how does someone not dealing with the > UI know the auth mechanism to use? When login happens, when account > creation happens, or when api signing happens (unaffected?)? Is there > an API call that lists the authenticators in use on the deployment? So > the appropriate cipher can be applied at client side? > > Also - could you list out a few tests that can be taken up to ensure > the feature is smoke tested. By that I mean - tests that will ensure > this feature isn't broken say when a new authenticator is used. I'm > looking to put them down as marvin tests. >
