On Tue, Jan 23, 2018 at 11:06 AM, Nadun De Silva <[email protected]> wrote:
> Hi, > > I have been working on *publishing events to IS Analytics* for the > notification system for the expired passwords. > > In the existing implementation to publish events to IS Analytics, a stream > and a publisher for each event type had been bundled together with IS. (The > artifacts are installed by the p2-feature at product-is build time) > > The publishing works as follows. > > 1. AbstractEventListeners in IS injects events into the stream. > 2. The publisher connected to the stream publishes to IS Analytics. > > If I am *to follow the same implementation* of publishing for the > password changed event, We would *need to add the relevant xml files to > the server*. > > There are several approaches that we can employ, that I could come up with. > > - Publish the connector as a p2-feature. (However, AFAIK, all the IS > connectors are published as jar files and therefore this may not be > suitable.) > > +1 to publish as connector for current version of the product. New config additions also can be added in connectors. > > - > - Bundle this along with the next release of IS. > > Must do this. At this point it will get published as p2 feature. > > - Let the user copy the files (This IMO is not very user-friendly.) > > Even if you publish as a connector we need to manually copy files. Regards, Johann. > What are your ideas on these approaches? Is there a better alternative? > > Any comments or suggestions are welcome. > > Thank you! > > Regards, > Nadun De Silva > > On Fri, Jan 19, 2018 at 2:21 PM, Nadun De Silva <[email protected]> wrote: > >> 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-no >>> tification/blob/master/components/event-handler-notification >>> /org.wso2.carbon.identity.event.handler.notification/src/ >>> main/java/org/wso2/carbon/identity/event/handler/notificatio >>> n/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+Val >>>>>>>>> idation >>>>>>>>> >>>>>>>>> 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 <+94%2077%20822%202607> >> Web: http://wso2.com >> >> <http://wso2.com/signature> >> > > > > -- > *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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
