Hi All, I agree with Johann, i.e. a) to publish as connector for current version of the product. b) to include this in next viable release in product itself.
On a different but related note, IMO connectors are really features, technically. Hence we need to look a way to be publish htme as features. Currently we add connectors to dropins. But this is not correct in terms of OSGI or the user experience perspective. I would think, "dropins" are for those components developed by users, not by WSO2. But there are problems in our WUM model when we do feature installation. We need to work on this too. Cheers, Ruwan On Tue, Jan 23, 2018 at 11:21 AM, Johann Nallathamby <[email protected]> wrote: > > > 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/mai >>>> n/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+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* > -- *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
