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. 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 Web: http://wso2.com <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
