I’m about to add a security layer to a new solution. I’m interested in how people are managing Security in their solutions, particularly if anyone’s utilized “security.setSecuritySettings” and what their strategy was.
I’ve already laid in users/groups and custom login in this solution. I want to add the ability to setup all the form and table security in the solution, by group. Also, I need the ability to setup other “permissions” for workflow operations that don’t map to Servoy security settings. They will be strictly ‘yes/no’ flags for things like “Can approve timesheet”, etc.
I also need to deal with how this system will handle migrations and updates to the application – because it’s likely to be a very dynamic application with lots of form and table changes in the near term. Whatever data structures I put in place to manage security will need to understand how to refresh themselves for these sort of changes over time.
Big topic Greg. Another self promotion warning but we’re fairly proud of how we handled security in our frameworks. (Servoy is also now selling their security “framework” that you may want to start from.)
We have an Access & Control module that allows us to control 3 main layers:
For us, each of these areas are data structures and defined in their own setup screens – navigation is generated from records, data records are obviously records, and “actions” are simply records whose existence you check in your workflow code (we call the actions setup screen an actions “registry”).
We have a group and login data structure (assign login records to a group record). All permissions are set at the group level by assigning which predefined data structures a group can access.
Besides the 3 main layers, the group record also controls a bunch of auxiliary items: admin modes, user modes, logging of user actions, servoy bars, our toolbars, and blogs.
The only real stumbling block with rolling your own security is record filtering. You cannot apply multiple addTableFilterParam() functions to a table. Our interface allows defining multiple solution-wide and multiple group level record filters (as this is logical from a user interface perspective). So we have a messy bit of logic going on to merge all the rules into one addTableFilterParam() call at login.
That’s the sum of it. Powerful, flexible (especially the actions abstraction layer which really cuts down the amount of spaghetti code at the workflow coding level), and easy to manage by a non-programmer. The Servoy security functions are all straight forward – it was the screen work to make everything data driven and user friendly that took quite a bit of work.
But once it’s done it’s done. Knowing you you could probably simplify all of this into about 50 lines of code for your purposes
P.S. New with 4.0 (well, it is hidden in 3.5) is the ability to control the view and accessibility of form elements by group.
I’m a bit lazy compared to David so what I do is basically link my group table records to a Servoy group, then I manage all the available navigation items in my code based on my group table and I define any extra security (elements readonly, tab panels not visible, etc) in Servoy groups using developer; the result is a system based on groups (my own) and macro-groups (servoy groups), I know it’s not perfect but it’s working pretty good and you don’t have to spend a lot of time for the majority of projects that don’t need such a complex security implementation.
agiletortoise:
Cool stuff, David…thanks for sharing.
So, if I understand right, you’re not using Servoy security at all in any of that…correct?
All the show/hide/access of fields and table level security is enforced by your own code?
greg.
Yup. Much easier to manage groups and users in your own data structures than messing around with Servoy’s security functions. The one exception is the record filtering and even that function is under the database manager.
And everything we are controlling is derived from record data (navigation, actions, etc). Which is the key to keep from going crazy if your forms are changing all the time, you have more than several groups and users, you want your clients to be able to set up their own permissions, and/or if your solution needs to be run in a SaaS (or even a multi-office) environment.
We haven’t implement the element level layer yet. And we will probably do that entirely with the Solution Model node instead of Servoy’s security.
Servoy’s security is comprehensive but the user interface for controlling everything is pretty basic and can only be done from developer.
