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.
