Hi Francesco,
> I'd go for more, like as adding to password policy specifications the options > for > > 1. not allowing values from other fields (including password) - note that > this feature for password and encrypted fields might not > always be available during user update, depending on the cipher algorithm Not allowing the value of the password field for the new password seems unnecessary to me - for this purpose one can use the password history, right? "Normal" schema attributes already work (PasswordPolicySpec.schemasNotPermitted), though I'm not sure if this also works for encrypted schema attributes. For my use cases, only the username is missing. AFAIK there is some special treatment of the username in the propagation handling (mapping, use of the username as account id), though I'm not too familiar with the code. Maybe one could do something similar in the password policy enforcement. > 2. not allowing values from a user-provided dictionary What would be the difference to PasswordPolicySpec.wordsNotPermitted? Cheers, Guido
