SVYX-206 - Add cyber security features to svySecurity

[SteveHawes]

Added the ability to log failed logins and auto-lock a user if they have too many failed login attempts. Also updated the svySecurityUX project to include the ability to view/search/filter failed logins when viewing the user details.

I have not implemented my suggestion of using svyProperties for the configuration variables but have opted to use scope variables for now to match the existing implementations but I can amend it to use svyProperties if you want.

[seanthomasdevlin]

Hi Steve,

Thanks for submitting this. It will be under review for a while as we are about to ship a new build of svySecurity. We have been holding off on any new features which introduce expansion of the data model (new tables for things like failed logins, password histories, etc.) We will revisit these kinds of features later this year.

Best,
Sean

[SteveHawes]

Hi Sean, No problem. If the new release includes the new user and tenant uuid fields and also the increased size for the username field that are currently in the master branch then there is one thing I noticed whilst doing this change that you may want to check before releasing: 1. The increased length for the username has been applied to the users table but not the sessions table which could cause relations issues. Look forward to the new release. Thanks Steve

…

________________________________ From: Sean ***@***.***> Sent: Monday, April 5, 2021 7:57:36 PM To: Servoy/svySecurity ***@***.***> Cc: Steve Hawes ***@***.***>; Author ***@***.***> Subject: Re: [Servoy/svySecurity] SVYX-206 - Add cyber security features to svySecurity (#31) Hi Steve, Thanks for submitting this. It will be under review for a while as we are about to ship a new build of svySecurity. We have been holding off on any new features which introduce expansion of the data model (new tables for things like failed logins, password histories, etc.) We will revisit these kinds of features later this year. Best, Sean — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFSUXN7VW4LDNCJWTBP5J73THIB2BANCNFSM42NC3CCQ>.

[pruhsert]

Thanks for letting us know about the user_name field length. There were actually three tables that were missing that change. Fixed that now.

[SteveHawes]

Hi Patrick, One other thing I meant to mention in the previous comment (I got sidetracked part way through the e-mail sorry) was that you might also want to consider changing line 206 of svySecurity.js so that it uses the new user_id field. Currently it is: if (!security.login(user.getUserName(), userUid ? userUid : user.getUserName(), groups)) { But if you change it to: if (!security.login(user.getUserName(), userUid ? userUid : user.getUserId(), groups)) { Then it will use the new user_id value for the security UID automatically. This ONLY works if you have populated the user_id field ie. the new postImport routine has been run. Just a thought. Thanks Steve

…

________________________________ From: Patrick Ruhsert ***@***.***> Sent: Monday, April 5, 2021 9:33:36 PM To: Servoy/svySecurity ***@***.***> Cc: Steve Hawes ***@***.***>; Author ***@***.***> Subject: Re: [Servoy/svySecurity] SVYX-206 - Add cyber security features to svySecurity (#31) Thanks for letting us know about the user_name field length. There were actually three tables that were missing that change. Fixed that now. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFSUXNZ2ARHZSAOZLPK455TTHINCBANCNFSM42NC3CCQ>.

[seanthomasdevlin]

We cannot assume they have generated the UUID values for upgraded implementations (That must be done by import hook, or some other trigger) so we still want to default back to username if no ID is present.

That is easy, but a bigger question is what to do with the 2nd arg of the login method. Because it is kind of conflicting with the user UID, if they have one. Perhaps we can check the user uid and if it is conflict then we can log a warning that is ignored.
We have already documented this: