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.

Reply via email to