Hi Dimuthu, I would suggest storing the expiration policy in IS side. How and where this can be stored yet to be discussed. For the time being, we can play around registry for quick start( but registry will go away soon) IS needs to emit an event towards analytics upon any change in the policy. This change will then be stored in analytics side too, and used as parameters on Siddhi (preferable) or Spark queries.
This will decouple the policy from the code. Hence "Identity Admin" is given chance implement most of things that can bed imagine. We provide default policy + default query. But "Identity Admin" can modify them without code change and change will be immediately live. Cheers, Ruwan On Tue, Jan 16, 2018 at 3:03 AM, Dimuthu Leelarathne <[email protected]> wrote: > Hi Nadun, > > > On Mon, Jan 15, 2018 at 9:01 PM, Nadun De Silva <[email protected]> wrote: > >> Hi all, >> >> I have started working on a Password Rotation Policy Authenticator for >> the Identity Server. >> >> Currently, there is an authenticator [1] which can be used to force the >> user to change the password. >> >> However, it does not support the following requirements on its own. >> >> - Force the user to change the password to a *previously unused >> password* >> - *Notify the user* when the password had expired >> >> According to my research, I found out that the *user can be forced to >> change the password to a previously unused password using the Password >> History Validation Policy* [2] and the authenticator [1]. However, the >> authenticator does not show a proper message to the user. I am planning to >> fix this. >> >> I have also started working on the *password expiry notifications*. The >> planned approach that will be used is as follows, >> >> - Emit the password change event to analytics >> - Use an analytic query to identify the user's whose passwords had >> expired >> >> > Where do we hope to maintain the password expiration policy? It is at the > identity server side. Can analytics query can invoke a REST API on identity > server side to retrieve it? > > thanks, > Dimuthu > > > This approach was selected as this will have a minimal load on the >> identity server instance as well as it will also open up the path to do >> further analytics to identify anomalous user behaviors. >> >> Any suggestions or improvements are highly appreciated. >> >> [1] https://store.wso2.com/store/assets/isconnector/details/ >> 502efeb1-cc59-4b62-a197-8c612797933c >> [2] https://docs.wso2.com/display/IS530/Password+History+Validation >> >> Thank you! >> >> Regards, >> NadunD >> >> -- >> *Nadun De Silva* >> Software Engineer | WSO2 >> >> Email: [email protected] >> Mobile: +94778222607 <077%20822%202607> >> Web: http://wso2.com >> >> <http://wso2.com/signature> >> > > > > -- > Dimuthu Leelarathne > Director, Solutions Architecture > > WSO2, Inc. (http://wso2.com) > email: [email protected] > Mobile: +94773661935 <+94%2077%20366%201935> > Blog: http://muthulee.blogspot.com > > Lean . Enterprise . Middleware > -- *Ruwan Abeykoon* *Associate Director/Architect**,* *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * *lean.enterprise.middleware.*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
