Howdy, howdy. Don't get up.

I've assigned four different privilege sets for the users that'll be using my solution (Admin, User, Reporter, and View-Only)...which is all fine and well if you have a few users. However, the User group alone will have 50+ separate people using it, so creating 50 account names (user1, user2, user3, etc.) is a klunky, and limited, way of doing things.

Is there an elegant way of assigning semi-Full-Access authority to an Admin account name so that person can create and assign accounts to his co-workers and underlings without getting into the guts of my solution? (I _definitely_ don't want the Administrator to have Full-Access authority since that's just inviting trouble to happen.)

TIA for your replies!

You are a perfect candidate for this...

http://www.scriptology.com/permissions

Is there an elegant way of assigning semi-Full-Access authority to an Admin account name so that person can create and assign accounts to his co-workers and underlings without getting into the guts of my solution? (I _definitely_ don't want the Administrator to have Full-Access authority since that's just inviting trouble to happen.)

By intent and design, there is not. It would be a serious security vulnerability. External Server Authentication is designed to address this item.

Steven

You are a perfect candidate for this...

http://www.scriptology.com/permissions

Thank you! I definitely know about that and already suggested it to my business partner to purchase it but he balked, saying that he doesn't want to buy anything that isn't recommended by someone. Well, now that I have yours... ::

Be careful with these ersatz systems. They can result in unauthorized privilege escalations.

Steven

I haven't looked under the hood, so I say this with a grain of salt - but this looks like a beefed-up user table laid on top of FileMaker's built in security. The Group metaphor used in the template looks akin to how we can use Extended Privileges to control script behavior across multiple priv sets, using PatternCount() and Get(ExtendedPrivileges).

Apparently the template leaves creation of individual user records in the User Table to the Manage Accounts & Privileges dialog. When a user logs in, if there's no user record in the user table matching the Account, one is created with no Groups assigned. Deleting a User record does not touch the user's Account. No passwords are stored.

Overall not a bad idea. It doesn't change anything about how schema access is managed via Accounts and Privileges. It just adds a method for grouping users together.

The presence or absence of those groups' "permissions" can then be checked when executing scripts...and internal Privilege Sets can be defined to check for their presence or absence as well, just like any other field.

A nice idea, since members of a Group can have different Privilege Sets...but rather complicated for the same reason. If I check for a currently logged in user's Groups' Permissions when running a script and return true, it's not the same thing at all as checking to see if that Privilege Set has access to the appropriate fields, layouts, creation/edit/delete privs and so on for proper script execution.

I don't know about it either. I just have seen a whole lot of these systems, and many of them are easily defeated to allow for privilege escalation.

If using FileMaker Server, External Server Authentication is your best bet in my view. Please rememebr that you do not have to have a domain controller to use External Server Authentication. FileMaker Server can handle it all.

Steven

Thanks for the advice, guys. Indeed, in the Permissions script vid from Matt P. he states that his solution doesn't take the place of FM's "front-end" security with privileges and Account Name setup, but as advertised it's a nice utility to for developers to assign to assign script-based privileges to users _after_ they've entered the solution...which will work very nicely in the solution I'm working on since it's a logistical nightmare right now as to whom is allowed to do what and when.

I, like other novice FM developers, hope we live long enough for FM to code a more robust security scheme.

I, like other novice FM developers, hope we live long enough for FM to code a more robust security scheme.

It's pretty robust now, and it's very granular. What changes are you seeking?

Steven

It's pretty robust now, and it's very granular. What changes are you seeking?

Steven

Activate/deactivate full access accounts via "conditional" script.

Ann

Activate/deactivate full access accounts via "conditional" script.

[color:red]By purpose, intent, design, and conscious decision scripts will not work on [Full Access] Accounts. This would be a severe security issue.

Steven

[color:red]By purpose, intent, design, and conscious decision scripts will not work on [Full Access] Accounts. This would be a severe security issue.

Steven

This would be...

Passware is...

Ann