Hi, *@Johann* Thank you for the information. I was able to extend the handler and listen to password change events.
Now I am working on publishing data to IS Analytics using the EventStreamService. I will keep the thread updated. Thank you! Regards, NadunD On Wed, Jan 17, 2018 at 2:14 PM, Johann Nallathamby <[email protected]> wrote: > > > On Wed, Jan 17, 2018 at 12:43 PM, Nadun De Silva <[email protected]> wrote: > >> Hi Johann, >> >> On Tue, Jan 16, 2018 at 9:30 PM, Johann Nallathamby <[email protected]> >> wrote: >> >>> Hi Nadun, >>> >>> On Tue, Jan 16, 2018 at 11:16 AM, Nadun De Silva <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> At the moment the authenticator only has the *"password expiration >>>> time period"* in the password expiration policy. >>>> >>>> So I can start off by altering the authenticator to publish the >>>> following to analytics >>>> >>>> - The password expiration time period config change >>>> - The password changed event >>>> >>>> Also, the high-level architecture would be as follows. >>>> >>>> >>>> >>>> >>>> Any comments or improvements are highly appreciated. >>>> >>> >>> There is a problem in this architecture. You are only considering the >>> password change events sent from the password rotation policy >>> authenticator. There are other channels also. E.g. SCIM2 and Admin Console. >>> So you need to publish the same event from there as well. This >>> should be pretty easy to do in IS with the handler architecture we have. >>> We should be already getting a password update event to the system whenever >>> user password is updated via any one of the above channels. Therefore all >>> you need to do is write a handler (or reuse an existing handler >>> appropriately) and create the siddhi streams and publish. >>> >>> My diagram was a bit incorrect. Sorry about the confusion I caused. >> >> This is not a class diagram and simply *shows how the events are >> published*. The updated correct high level diagram which uses a listener >> is shown below. >> >> >> >> My current approach after more research is to extend the >> *UserOperationEventListener* [1] >> <https://github.com/wso2/carbon-kernel/blob/release-4.4.20/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/listener/UserOperationEventListener.java> >> and >> listen to the following events. >> > > From IS 5.3.0 onwards we don't use *UserOperationEventListener* anymore. > We have one single *UserOperationEventListener* that publishes events for > the operations you have mentioned below. And there are IdentityHandlers > which listen to to those event and do stuff. You need to write a > IdentityHandler. For example [1]. > > [1] https://github.com/wso2-extensions/identity-event- > handler-notification/blob/master/components/event- > handler-notification/org.wso2.carbon.identity.event.handler. > notification/src/main/java/org/wso2/carbon/identity/ > event/handler/notification/NotificationHandler.java > > Regards, > Johann. > >> >> 1. User Add [2] >> >> <https://github.com/wso2/carbon-kernel/blob/release-4.4.20/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/listener/UserOperationEventListener.java#L90> >> 2. User Credentials Update [3] >> >> <https://github.com/wso2/carbon-kernel/blob/release-4.4.20/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/listener/UserOperationEventListener.java#L119> >> 3. User Credentials Update By Admin [4] >> >> <https://github.com/wso2/carbon-kernel/blob/release-4.4.20/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/listener/UserOperationEventListener.java#L144> >> >> This will handle the publishing of the password change events to siddhi. >> >> >>> With that can we remove this Password Expiration Policy authenticator >>> from the design? Is there any other requirement for this? Looking at the >>> "inheritance" relationship worries me :) >>> >> >> With the current approach the *authenticator* will only be used to force >> the user to reset the expired password in the *authentication flow*. >> >> The "authenticator" and the "listener to publish the relevant events" >> will be separately implemented and *bundled them together in one >> connector*. (Including a C-App containing the IS-Analytics artifacts) >> >> I hope this solves the concerns pointed out before. >> >> Please correct me if I am wrong and any comments or improvments are >> highly appreciated. >> >> Thank you! >> >> [1] https://github.com/wso2/carbon-kernel/blob/release-4.4.2 >> 0/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carb >> on/user/core/listener/UserOperationEventListener.java >> [2] https://github.com/wso2/carbon-kernel/blob/release-4.4.2 >> 0/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carb >> on/user/core/listener/UserOperationEventListener.java#L90 >> [3] https://github.com/wso2/carbon-kernel/blob/release-4.4.2 >> 0/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carb >> on/user/core/listener/UserOperationEventListener.java#L119 >> [4] https://github.com/wso2/carbon-kernel/blob/release-4.4.2 >> 0/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carb >> on/user/core/listener/UserOperationEventListener.java#L144 >> >> Regards, >> NadunD >> >>> >>> Regards, >>> Johann. >>> >>> >>>> Thank you! >>>> >>>> Regards, >>>> NadunD >>>> >>>> On Tue, Jan 16, 2018 at 6:39 AM, Ruwan Abeykoon <[email protected]> >>>> wrote: >>>> >>>>> 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.* >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Nadun De Silva* >>>> Software Engineer | WSO2 >>>> >>>> Email: [email protected] >>>> Mobile: +94778222607 <+94%2077%20822%202607> >>>> Web: http://wso2.com >>>> >>>> <http://wso2.com/signature> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Johann Dilantha Nallathamby* >>> Senior Lead Solutions Engineer >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile: *+94 77 7776950* >>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>> <http://www.linkedin.com/in/johann-nallathamby>* >>> Medium: *https://medium.com/@johann_nallathamby >>> <https://medium.com/@johann_nallathamby>* >>> Twitter: *@dj_nallaa* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Nadun De Silva* >> Software Engineer | WSO2 >> >> Email: [email protected] >> Mobile: +94778222607 <+94%2077%20822%202607> >> Web: http://wso2.com >> >> <http://wso2.com/signature> >> > > > > -- > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile: *+94 77 7776950* > LinkedIn: *http://www.linkedin.com/in/johann-nallathamby > <http://www.linkedin.com/in/johann-nallathamby>* > Medium: *https://medium.com/@johann_nallathamby > <https://medium.com/@johann_nallathamby>* > Twitter: *@dj_nallaa* > -- *Nadun De Silva* Software Engineer | WSO2 Email: [email protected] Mobile: +94778222607 Web: http://wso2.com <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
