Hi Asela, While agreeing the concerns of separate pack, we have different concerns too to address,
1. We are moving towards micro-services world and container nativeness. Adding more functionalities into single JVM is not the best move. The idea is on service do single task to the best. 2. Due to load on the server on querying the database on scheduler. We have seen this problem in notorious session cleanup task. Iterating over all the records in a live DB while modifying the same set of records is considered a dangerous thing. This can not be done in theory. Yes, some users opt doing this with iterating over user store. This is fragile and bound to be failed an any point of time. So, lets do the correct thing, let the analytics do things it is strong and lets keep things simple. Also since we emit the events, customer is not tied to DAS or IS analytics. They can insert those in their own structure (May be RDBMS, REDIS, elastic search) and do any queries they wish, such as writing custom scripts. So we are allowing more possibilities with this approach (not providing hard set of functionalities inside IS). Cheers, Ruwan On Tue, Jan 16, 2018 at 2:32 PM, Asela Pathberiya <[email protected]> wrote: > > > On Tue, Jan 16, 2018 at 2:01 PM, Nadun De Silva <[email protected]> wrote: > >> Hi Asela, >> >> On Tue, Jan 16, 2018 at 12:14 PM, Asela Pathberiya <[email protected]> >> wrote: >> >>> >>> >>> 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 >>>> >>> >>> Do we need to deploy an analytic instance to use this authenticator... >>> Is it something mandatory ? >>> >>> If we use the current approach mentioned before, the analytics instance >> is *not required to use the* *authenticator*. However, the analytics >> instance would be *required to use the password expiration notifications*. >> If the user does not use the analytics instance only the notifications will >> be disabled. >> >> >>> Can we simply store & implement task inside WSO2IS to achieve this ? >>> >> >> We did consider spawning a task to achieve this. But there were several >> issues pointed out in our discussions. >> >> - If the task is inside the identity Server instance, it will have a >> periodic workload of going through all the users and finding the users >> whose passwords had expired. >> - This is especially a concern when the number of users is really >> high. >> - Siddhi or a Spark query will be able to handle this more >> efficiently. >> - By using the analytics instance and only emitting the password >> changed events from the identity server we can decouple the notifications. >> - This gives the admin more freedom over the notifications. >> - We can do further analytics to identify anomalies and threats. >> >> > Got it. But in a user/customer point of view, I just need to configure an > authenticator to achieve password expiry notification with WSO2IS. For > that; I need to download separate pack & install it in separate java > instance & maintain it separately. It is cost. Why i am spending this > much of cost to enable this feature ? IMO; we need to think of that > aspect as well. > > I have seen some users have already implemented a small script which calls > the LDAP user store & verifies the password updated date & sends mails. > > Thanks, > Asela. > > >>> Thanks, >>> Asela. >>> >>> >>>> - 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. >>>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> Asela >>> >>> ATL >>> Mobile : +94 777 625 933 <+94%2077%20762%205933> >>> +358 449 228 979 >>> >>> http://soasecurity.org/ >>> http://xacmlinfo.org/ >>> >>> _______________________________________________ >>> 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> >> > > > > -- > Thanks & Regards, > Asela > > ATL > Mobile : +94 777 625 933 <+94%2077%20762%205933> > +358 449 228 979 > > http://soasecurity.org/ > http://xacmlinfo.org/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *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
