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 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