Jump to content

Simple security at AccountName level


This topic is 3192 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Perhaps this post is more relevant in the 'calculation engine' sub-form, so please forgive me if I'm in the wrong place.

I have implemented layout based account management via this site:

http://www.modularfilemaker.org/module/accounts-modular-user-account-management/

I am very pleased with how it all came together, but I want to take it a step further.

By using the "Hide Object" feature I want to implement some security at the account name level, rather than creating extensive privilege sets. I am looking to create some additional fields within the "Accounts" table that the above example features that contains boolean results that will be controlled by checkboxes. This is the easy part, however there are some buttons I want to hide from select users, no matter what privilege set their account is under. For example, my solution features a private messaging feature that is accessed via the dashboard. For users that (for examples sake) abuse the PM system I can temporarily "switch" off their access to that layout which in turn would remove the PM button from their dashboard. A user under the "Manager" or "Full Access" privilege set could then switch the feature back on at a later time by unchecking the correlating box within the Account table.

How should I set up the calculation that is inserted into the "Hide Object" feature that will reference the account name and the users related record within the Account table to determine a true or false result?

Link to comment
Share on other sites

I understand layout-level security is a rather taboo subject on these boards, however it is a route I've decided to take due to the fact I won't always be around to administer account creation and I don't want managers having access to the native FileMaker security dialog or make them wait for me to have time to log into their solution to create or remove an account. The data contained within my solution isn't really that sensitive, so I'm not overly concerned with the database being 100% buttoned down.

In an attempt to re-word my question, I want to be able to control a few features at the account name (user name) level that will prevent the need for excessive privilege sets to be created. On the account management screen where the users are listed I want to have some checkboxes that the Manager can easily check/uncheck that would hide some buttons from the selected user... in the example from my first post, for user Betty, one check box might be "Hide access to PM system" - if checked, Betty won't see the PM button on her dashboard when she next logs in. While the creation of the necessary check boxes and toggling of 1 or 0 isn't where I'm struggling, I'm not quite sure what the calculation should be for the Hide Object feature that would check the active account name with the account name within the account table.

Link to comment
Share on other sites

I am afraid we are not exactly on the same page.

First, I am not aware of any subject (that is a Filemaker-related subject) that is taboo here.

Second, managers can certainly use scripts to administer accounts. That's not layout-level security (if implemented properly). Layout-level security means preventing user's access to a layout object that facilitates an action (such as hiding a button that creates a message), instead of taking away their privilege to perform the actual action (i.e. create new records in the Messages table).

 

 

In any case, you will want to consult the status of the checkbox field in the Accounts table from whatever table your dashboard layout is based upon.

So you'll need to do one of these:

  1. Base the dashboard layout on the Accounts table and direct each user to their own record at startup (this should be automatic, since they shouldn't have access to any other record anyway);
  2. Define a relationship between the two tables based on matching an unstored calculation field = Get (AccountName) with Accounts::AccountName;
  3. Populate a global field (not a variable!) with the user's status at startup. Make sure user that the default value is 0 (deny) and that the user has no privileges to modify this field.

 

Edited by comment
Link to comment
Share on other sites

Thank you for your help, Comment. 

My apologies for the misunderstanding in my previous post. I suppose this could apply to any scenario - say the user is brand new to using the solution. There could be a check box under their account data to display pop-over buttons that contain directions on layouts while they learn the system... a manager could then turn off these pop-over buttons that contain the directions (by unchecking the box) once they're satisfied the user knows what they're doing. 

Edited by madman411
Link to comment
Share on other sites

say the user is brand new to using the solution. There could be a check box under their account data to display pop-over buttons that contain directions on layouts while they learn the system... a manager could then turn off these pop-over buttons that contain the directions (by unchecking the box) once they're satisfied the user knows what they're doing. 

Right. But that's not security-related, so there's no problem with implementing this purely on layout level.

I should add that often you will want to implement layout-level measures in addition to security - such as hiding/greying out the button that won't work for the current user.

Link to comment
Share on other sites

Just so there is no misunderstanding here:

The User Interface is not part of the Security Schema for files and tables and scripts.

Hiding a button does not disable the underlying action that the button would trigger.

If the process by which the "manager" sets the checkboxes is not protected, it can be manipulated and by-passed.

If you need to implement security features to prevent a class of users from having access to data or prevent them from initiating portions of the file's business logic, you must do that through the Privilege Set's privilege bits.

It is interesting that this item arises at this particular time. In less that three weeks, at the 20th Anniversary FileMaker Devcon, I will be showing the results of reliance on the UI and other such elements for "security" purposes.  Those results are not at all beneficial or effective.

 

Steven

  • Like 1
Link to comment
Share on other sites

The Modular FileMaker file you're referring to is script-based account management. It's not "layout-based".

If you have a limited number of combinations of layouts/layout objects you want to hide, say a dozen, go ahead and create separate privilege sets for those, limiting layout access. Then for the objects, you can put a simple get ( AccountPrivilegeSetName) for the Hide calculation. Also, take a look at Extended Privileges. That may be a better way to conditionally hide objects than the Privilege Set Name.

If you got hundreds of possible combinations (new user, PM abuser, accountant, etc etc etc etc) that would required hundreds of privilege sets...then you may want to look at another solution.

 

 

Link to comment
Share on other sites

I understand layout-level security is a rather taboo subject on these boards, however it is a route I've decided to take due to the fact I won't always be around to administer account creation and I don't want managers having access to the native FileMaker security dialog or make them wait for me to have time to log into their solution to create or remove an account.

Not taboo, just a really bad idea - which is why it gets discouraged.

As to the underlying premise: use External Authentication.  That takes the account management outside of FM and into the hands of an admin that does not need to ever go into FM at all.  Not unless a new set of roles is defined - which would be part of normal FM development work anyway.

If EA is not possible for some strange reason then look at something like Security Administrator from New Millennium.  That too takes account creation outside of your main solution.

So fix the problem where it should be fixed, not by compromising the security of your solution.

  • Like 1
Link to comment
Share on other sites

This topic is 3192 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.