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. > 20/core/org.wso2.carbon.user.core/src/main/java/org/wso2/ > carbon/user/core/listener/UserOperationEventListener.java > [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 > [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 > [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 > > 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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
