Observations & ideas for transition to .fp7 security model
Proposed new security system for ebase 2.20.fp7
Introduction
ebase in .fp5 handled most aspects of security using custom scripts; all regular users shared a common, invisible (auto-entered) FileMaker password, and logged in using a custom-scripted process. This approach was necessary because ebase's requirements exceeded the capacity of FileMaker native security features.
Some of ebase's requirements (notably the ability to store a number of user attributes, such as default log code and data editing privileges) still exceed FileMaker 8.5's native feature set. On the other hand, FileMaker's ability to provide richly configurable user privileges now exceeds ebase's old security features.
I suggest we consider the following suggestions, and revise ebase's security model (including login process) to let FileMaker handle what it now can, reserving custom scripting for only what FileMaker cannot handle.
1. Problem:
Password is case sensitive in .fp7 format, and admin password was not entered consistently across all ebase files.
Suggestion:
Establish [full access] privilege group and 1 uniform login/password in this group for all files:
Admin/admin
2. Privilege group must be established for day-to-day use. This group should have access to edit data & view layouts, but not to edit scripts or layouts.
Suggestion: create a second privilege group in all files (for now I'll call it "staff") with the necessary access settings.
3. Lots of files! Some contain data, and need careful access restriction. Others don not contain data, and could share a common password.
Suggestion:
a) Set all files that don't contain data to auto-enter a default staff-level password on launch.
b) For files that contain data (Contacts, Log, Location, Links, ContactLocations, CodeGenerator, ebase, Main, EmailArchive, EmailInBox, EnhancedData...), establish scripts to add, revise, and remove staff-level user accounts.
4. DBA needs to be able to add-remove user accounts without developer login.
Suggestion: Add scripts to ebase.fp7 that allow DBA to establish/edit/remove user accounts. These must call subscripts in each of the files mentioned in 2b above to establish/edit/remove accounts in all necessary files at once.
5. Original login process depends on dialog plug-in, with one FM password and custom handling of security & privileges.
Suggestion: transition to using FileMaker accounts & privilege groups for security (as described above), and only maintain ebase-specific settings in ebase.fp7 user account records. Revise log-in script to load ebase-specific settings to globals as necessary after user gets past FM login process.
- Printer-friendly version
- Login to post comments
Proposed new security system for ebase 2.20.fp7
While this looks mostly right in theory, I fear that the current ebase file structure has way too many files to safely use the FileMaker passwording. If we are talking about adding a new password to ebase this way it would have to run a script in every ebase file to create or remove Fm privleging.
Under some conditions, If something went wrong with this process there is no way we would ever be able to breakin and fix it. We could have files or a whole ebase that become totaly unreachable.
My sugestion is as long as there are many files to ebase, stay with fixed FM privleging and an overlay of password processing inside ebase.
Interim measure
Thanks for looking this over, Clif.
For the same reason (and also for expediency), I proposed only passwording a few of the files, not all. The process I proposed does require calling subscripts in each file, but in my experience, with Allow User Abort turned off, it's fast and reliable.
Note that the developer password, admin/admin, is intended to remain always in this approach... a machine crash in the middle of creating or updating a user account could hose that account, but other accounts and the admin [full access] account would remain.
One of my goals for a FM 8 port is to not use plugins (if possible)... I've tried implementing a login window using a FileMaker layout, but ran into trouble with cross-platform issues for the bullet font (used to obscure password text). It seems that a dialog plugin (like you're using) or FileMaker's native account login are the two easy solutions. Do you have a suggestion for how to stay with a single FM user account and let ebase handle logins without resorting to an external plugin?
Thanks,
Allen
re the font for password, in
re the font for password, in a pinch in the past I've just used a white font on a white field background. Works OK. Not as good as bullet, but at least the blinking cursor moves as the user types and the pwd isn't visible over the user's shoulder unless they select the text.
You could also have two layouts (or two stacked fields), one for each platform and using the appropriate font, and have scripts activate the correct one.
Allen's approach sounds OK to me, although I share Clif's concerns somewhat. I'm wondering if it would make sense to try to integrate some of the files in the first FM8 release - those that are mainly just data with very little or no interface. For example, would it be too much work to roll Locations and ContactLocations into Contacts? With the ability in FM8 to import tables, maybe it could be done relatively quickly??
The other thing I'd ask for (and this could be part of a later release) would be to make it easy for anyone who wanted to use external server-based authentication. Especially on the Mac, this seems to be a great way to go if you've already got a file server set up.
Eventually I think we should provide easy avenues and reminders to users to deactivate or change passwords on all default admin accounts.