Hi Guido,
it seems I was too quick and did not check the actual PasswordPolicySpec
implementation before sending - excuse me, I am in the middle of the
deep refactoring for SYNCOPE-620 and my mind is a bit blown out :/
You are right, only username is missing for fields not acceptable as
password value: would you mind to open an improvement on JIRA?
Finally, since we'd need to extend PasswordPolicySpec and possibly some
classes in the policy evaluation process (say PolicyEvaluator), I
believe we should set the fix-for-version of this improvement to 1.3.
Regards.
On 30/12/2014 10:32, Guido Wimmel wrote:
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
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
