On Tue, Jan 16, 2018 at 9:11 PM, Johann Nallathamby <[email protected]> wrote:
> > > On Tue, Jan 16, 2018 at 8:27 PM, Ruwan Abeykoon <[email protected]> wrote: > >> 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). >> > > +1 for this architecture. > > *@Asela*: the incremental cost seems to be big only because we only have > a few of things right now we get from IS Analytics. The Analytics > dashboards, Suspicious activity alerts, Session termination and now this > new feature. But there are some more features IAM team is planning to do > using IS Analytics in the space of fraud detection and threat > intelligence. Once we have tapped the full potential of IS Analytics users > will see the value I think. Spinning up an additional server won't be seen > as costly then. > Agreed on above! My concern is that; when we are introducing a new feature/improvement, It is better to have an easy way which will help users/customers to try out without any cost. Yes! extensible/distributed deployment must be there. > > Regards, > Johann. > > >> >> 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+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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >> >> > > > -- > > *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* > -- Thanks & Regards, Asela ATL Mobile : +94 777 625 933 +358 449 228 979 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
