Hi Pushpalanka/Isura,
On Mon, Jun 20, 2016 at 4:50 PM, Pushpalanka Jayawardhana <la...@wso2.com> wrote: > Hi Isura, > > On Mon, Jun 20, 2016 at 10:52 AM, Isura Karunaratne <is...@wso2.com> > wrote: > >> HI all, >> >> I am working on $subject for WSO2 Identity Sever 5.3.0 release. Following >> are the currently identified improvements, >> >> >> - Password History - >> >> Last 'n' number of passwords need to be maintained in user's history. >> When user updates his password we don't allow him to choose one of these >> 'n' passwords again. >> >> >> - Periodic Password Reset - >> >> Force the user to periodically (configurable period) reset his password. >> When doing this we need to leverage the password history feature as well. >> >> >> CREATE TABLE IF NOT EXISTS idn_password_history_data >> ( >> user_name *VARCHAR*(255) NOT NULL, >> user_domain *VARCHAR*(255) NOT NULL, >> tenant_id *INTEGER* DEFAULT -1, >> hash *VARCHAR*(255) NOT NULL, >> time_created *TIMESTAMP* NOT NULL DEFAULT >> CURRENT_TIMESTAMP, >> PRIMARY KEY (user_name,user_domain,tenant_id, >> hash), >> ) >> >> >> All the passwords which are supposed to store in this table are old >> passwords (expired). >> >> - I think we don't need to use the same password hashing algorithm (with >> or without salted value) which is defined user-mgt.xml for password history >> validation. >> - admin users can change other user's passwords without giving their old >> passwords. In that case, how can we find the old password hash value to >> store for password history validation? >> > In the given table schema we may need to pay special attention to handle > user_domain, as secondary user store domain can be changed. Ideally we > should incorporate a *unique user store domain id* than using user domain > here. > We already have a listener to handle user store domains related operations called 'AbstractUserStoreConfigListener'. This listener provides " onUserStoreNamePreUpdate" and "onUserStorePreDelete" methods, which we can use here to modify "idn_password_history_data" table accordingly. Also these methods work with user store domain name. You can refer [1] for such implementation. > >> >> Your comments and suggestions are highly appreciated. >> >> Thanks >> Isura. >> >> >> Isura Dilhara Karunaratne >> Senior Software Engineer >> >> Mob +94 772 254 810 >> >> >> _______________________________________________ >> Architecture mailing list >> architect...@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Pushpalanka. > -- > Pushpalanka Jayawardhana, B.Sc.Eng.(Hons). > Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/ > Mobile: +94779716248 > Blog: pushpalankajaya.blogspot.com/ | LinkedIn: > lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka > > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > [1] - https://github.com/wso2-extensions/identity-user-account-association/blob/master/components/org.wso2.carbon.identity.user.account.association/src/main/java/org/wso2/carbon/identity/user/account/association/internal/UserStoreConfigListenerImpl.java -- *Thanuja Lakmal* Senior Software Engineer WSO2 Inc. http://wso2.com/ *lean.enterprise.middleware* Mobile: +94715979891 +94758009992
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
