Documenting a development's security in a database

April 9, 201411 yr

Let's face it. If you have a security consious customer and a large development with different security groups, external authentication, IOS, webdirect, XML and php access, encryption, SSL, firewall setup and whatever I'm forgetting here, you kinda lose track.

FileMaker has no conventient way of immediately letting me assign security to an object ( a field, a layout or a script ) when I create it, so there's an additional danger of creating security holes if you are not submitting yourself to the regular ritual of reviewing security after a chunk of development.

FileMaker security interface is not bad, but sometimes a bit awkward to use, leaving room for errors. One has to systematically review every security group for layout access, field access and script access, instead of doing this centered from the objects themselves.

Having a pessimistic approach to security will not solve this, but results in bug reports of people ( if they care to do so ) not able to access newly made objects. Your security holes are plugged, but your development quality would suffer.

It looks to me that regularly reviewing the security properties of a development is a required ritual, and some kind of database system is required that can update itself with a feed from the database and indicate newly created objects, so I can systematically assign the correct security features, and apply them in the development itself. If some security group's privileges change over time, I should be able to get a check list to see what I should change in the FileMaker security dialogs. This database would document how the security should be set in the database.

I'm not looking to reinvent the wheel, so I DO NOT want to have an alternative security system in FileMaker. I just want a FileMaker database where I can sytematically document security on all levels. I'm wondering if anybody has ever made such a thing. I'm faced with developing it, and if there is a product available, I could probably cut development cost.