On Sun, Jan 22, 2017 at 3:20 PM, Isura Karunaratne <is...@wso2.com> wrote:
> Hi Prabath, > > > On Fri, Jan 20, 2017 at 4:43 PM, Prabath Siriwardena <prab...@wso2.com> > wrote: > >> Hi Isura, >> >> Please find my comment inline... >> >> On Fri, Jan 20, 2017 at 2:02 AM, Isura Karunaratne <is...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> >>> We are working on implementing account lock/disable features for IS >>> 6.0.0. >>> >>> *Account Lock: * >>> >>> - User *must not *be able to login to the system. >>> - Admin user *can* update the user attributes and assign roles >>> (account is active) >>> - User cannot start a password recovery flow. >>> >>> >> In summary the user cannot do any actions with the system - but the >> Administrators can. >> >> >>> *Account Disable: * >>> >>> - User *must not* be able to login to the system. >>> - Admin user *can not* update the user attributes and cannot assign >>> roles until enabling the account. (inactive state) >>> - User cannot start a password recovery flow. >>> >>> Neither the user nor the Administrator can do any actions on this user. >> Special case, the Administrator can enable the user account. >> >> >>> >>> >>> *When will the account be locked?* >>> >>> >>> >>> - Self Signup users until account confirmation >>> >>> This is special status - and we need to identify this status different >> from the account lock. A user in this status can request to resend the >> confirmation code. >> >> Also one (an Administrator) should be able to setup a policy to wipe out >> all the unconfirmed accounts after sometime. Also there can be cases we >> still let unconfirmed users login to the system - but only a limited set of >> functionality is allowed. >> >>> >>> - Try to login with invalid credentials more than configured number >>> of attempts. Then the account will be locked configured amount of time. >>> (Like 5 minutes). This lock time will be increased if the user locked >>> again >>> based on a configuration. >>> - Provide invalid answers more than configured number of attempts, >>> when password recovery >>> - User onboarding with Email/SMS verification flow. >>> >>> Applies the same comment here - for the self-signup >> >>> >>> - When admin needs to block the user to login to the system >>> - When admin initiated password reset flow starts. >>> >>> We need to identify this states different from the account lock.. >> > > Since we have multiple states for different scenarios, shall we implement > the state transition (life cycle) like Johann explain in [1] > > [1] [Architecture] Lifecycles for Identity Management > +1 I also think what we are discussing here is lifecycle of an 'identity' and thinking such a way provide more flexibility and extensibility. I guess we can reuse new lifecycle component developed by API-M team as well. Thanks ! > > Thanks > Isura > >> >>> >>> *When will the account be disabled?* >>> >>> >>> >>> >>> >>> - When admin needs to inactivate user. >>> >>> >>> >>> What is the best way handle account disable check? We can do this from a >>> inceptor level, then we need to check account disable in each operation. >>> >>> Thanks >>> Isura. >>> >>> >>> >>> >>> >>> *Isura Dilhara Karunaratne* >>> Senior Software Engineer | WSO2 >>> Email: is...@wso2.com >>> Mob : +94 772 254 810 <+94%2077%20225%204810> >>> Blog : http://isurad.blogspot.com/ >>> >>> >>> >>> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Twitter : @prabath >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >> >> Mobile : +1 650 625 7950 <(650)%20625-7950> >> >> http://facilelogin.com >> > > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Sagara Gunathunga Associate Director / Architect; WSO2, Inc.; http://wso2.com V.P Apache Web Services; http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
