Reputation: 21
Am having a requirement to set Password History limit in WSO2 - IS, i.e if my current password is "Abc123", and if am trying to changing the password with "Abc123" again, it should not accept.
If I set my password history limit as "3", then the new password should be different from last 3 password given for that particular account.
Please share your insight on this and help me to achieve the task.
Upvotes: 0
Views: 244
Reputation: 11
Actually, WSO2-IS does not support password history control out of the box. This is a limitation in the current implementation since it is connecting to the user store with the super admin credentials of the User Store always. The best option is that you can write custom listener (extension) and plug it with the Identity Server.
Listener is an extension to extend the user core functions. Any number of listeners can be plugged with the user core and they would be called one by one. By using listener, we are not overriding the user store implementation, which is good as we are not customizing the existing implementations. Let see how it works.
Every time when user core method is called, all the listeners that are registered with that method, are called. Listeners can be registered before or after the actual method is called. Let take some example; In user core, there is a method called “addUser()“. When user is created in Identity Server, “addUser()” method is called. You can register a listener before the actual execution of “addUser()” method and also, you can register a listener after the actual execution of “addUser()” method. “addUser()” method can be seen as follows.
addUser() {
preAddUser(); // you can implement this using listener
actualAddUser();
postAddUser(); // you can implement this using listener
}
Both “preAddUser()” and “postAddUser()” method can be customized as you want. It means, you can do some custom things before user is added or after user is added. All the method in user core has been implemented as above. It means that you can customize them before and after…
Let take following simple scenario.
When user is authenticated with LDAP, there is a requirement to add authenticated time as an attribute of the user. Therefore we need to write some custom code after successful user authentication is happened. Following is the custom listener implementation for this. “doPostAuthenticate()” method would be called after actual user authentication is done.
package org.soasecurity.user.mgt.custom.extension;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.wso2.carbon.user.core.UserStoreException;
import org.wso2.carbon.user.core.UserStoreManager;
import org.wso2.carbon.user.core.common.AbstractUserOperationEventListener;
/**
*
*/
public class MyUserMgtCustomExtension extends AbstractUserOperationEventListener {
private static Log log = LogFactory.getLog(MyUserMgtCustomExtension.class);
@Override
public int getExecutionOrderId() {
return 9883;
}
@Override
public boolean doPreAuthenticate(String userName, Object credential, UserStoreManager userStoreManager) throws UserStoreException {
// just log
log.info("doPreAuthenticate method is called before authenticating with user store");
return true;
}
@Override
public boolean doPostAuthenticate(String userName, boolean authenticated, UserStoreManager userStoreManager) throws UserStoreException {
// just log
log.info("doPreAuthenticate method is called after authenticating with user store");
// custom logic
// check whether user is authenticated
if(authenticated){
// persist user attribute in to user store
//"http://wso2.org/claims/lastlogontime"
is the claim uri which represent the LDAP attribute
// more detail about claim management from here http://soasecurity.org/2012/05/02/claim-management-with-wso2-identity-server/
userStoreManager.setUserClaimValue(userName, "http://wso2.org/claims/lastlogontime", Long.toString(System.currentTimeMillis()), null);
}
return true;
}
}
Likewise, you can add custom extensions to any method of the user core.
Here, I would like to note following things.
“getExecutionOrderId()” can return any random value. This would be important when there are more than one listeners are in the identity Server and you need to consider about execution order of them
All the methods are return a boolean value. This value mentioned, whether you want to execute next listener or not.
Let see what are steps to configure the custom implementation.
Step 1. Listeners are registered as OSGI components. Therefore you need to register this class in OSGI framework. You can go through this which is the complete project.
Step 2. Copy OSGI bundle file in to IS_HOME/repository/components/dropins directory.
Step 3. Restart the server.
Upvotes: 1
Reputation: 443
In case you are using LDAP as user store then you may apply the password policy there itself. You may assign the password history count over there in LDAP.
In case you wan to do it in WSO2 IS itself then you may need to write a custom password policy extension
Upvotes: 1