Hi guys.
We're using Apache Syncope 2.0.12.

Currently, we're starting to implement customization in Syncope Core to enforce 
the already created users to change their passwords if password lifetime 
expired. The password lifetime is a domain-specific value in our case. And 
we're planning to store it in our custom implementation of 
@org.apache.syncope.common.lib.policy.AbstractPasswordRuleConf@

The plan is to implement Password Expiry Scheduled Task by analogy as mentioned 
here 
https://cwiki.apache.org/confluence/display/SYNCOPE/Configure+a+PasswordExpirationJob.
 What we want to achieve is to propagate the @mustChangePassword@ field in AD 
as well, but first, we need to find all the users, whose password should be 
updated, correctly. In the example above you provided the following query 
"SELECT id FROM SyncopeUser WHERE changePwdDate < ?1".

What we noticed is that @changePwdDate@ field is not initialized when we create 
a new user with the specified password in Apache Syncope. What is the purpose 
of why the logic is implemented in such a way?
Currently, @changePwdDate@ field is updated only when UserTO object is updated.
Can we also init changePwdDate when we create a user and specify the password 
by adding this line? 
https://github.com/apache/syncope/blob/d3b81598d63a04132e271fbc75a964aa48f39e7f/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/UserDataBinderImpl.java#L171
```java
        user.setChangePwdDate(new Date());
```

Also AD supports the "passwordNeverExpires" flag. For this purpose we would 
like to add a new "passwordNeverExpires" field in 
org.apache.syncope.core.persistence.jpa.entity.user.JPAUser model.
We want to have this field to exclude users which have "passwordNeverExpires" 
set to @true@ in Password Expiry Scheduled Task. Do you see any sense to have 
this field in the code of Apache Syncope as well (as a part of JPAUser entity 
and then as a part of UserTO object)? Can this field be applied to other types 
of net.tirasa.connid connectors?

Kind Regards,
Dmitriy Brashevets

Reply via email to