Separation model & account management

[Dominiek C.]

I am wondering how to employ the new security system (management of accounts and passwords) in the separation model.

I assume that all security settings should be the same in both files (data and user interface) ?

If so called 'super users' are allowed to create accounts, how do you manage this in a secure way ?

[The Shadow]

You can make scripts to create accounts that have the "Run script with full privileges" checkbox set. Then make these scripts executable only by your "super user" privilege set.

[Kurt Knippel]

You control it through scripting. There are script steps that allow you to add/edit/delete accounts. You have a table in your main file that stores the accounts and then scripts in all your other files that add/edit/delete those accounts.

Or you as the developer, sets it up once and does not change it.

[Dominiek C.]

You control it through scripting. There are script steps that allow you to add/edit/delete accounts. You have a table in your main file that stores the accounts and then scripts in all your other files that add/edit/delete those accounts.

Fine. But what about the password management ?

Assuming there is an 'Interface'- and a 'Data'-file. When a user is logged in on the 'Interface'-file, what happens if he changes his password ? His password of the 'Interface'-file is no longer the same as his password of the 'Data'-file. Using the 'Interface'-file, does this user still has access to the data in the 'Data'-file ?

I assume that it is not possible to propagate the password change over multiple files ?

[321]

Dominik,

I have not tried this yet, but if you use external authentication (if you have that option) for both the data and the interface file, I am assuming that when the user changes his or her windows log in password, the password will change in both the data and interface file, as they are both externally authenticated.

[The Shadow]

You can turn off the user's ability to change their own password. Then, the only method to change it is via your SuperUser scripts, which can use the Reset-Account-Password script step to change it.

[RDecker]

> I assume that all security settings should be the same

> in both files (data and user interface) ?

Two questions:

1. If this is correct (must have same settings in data and interface--which sounds right to me), is there any way to set this up apart from manually opening each file and making sure that every setting is identical? (I'm working with a project that has one interface file and 6 data files.)

2. Are there any differences or considerations relevant here to the stand alone version created with developer?

Thanks,

RD

[RalphL]

1. Why? In my interface file there are no tables. The layouts reference TO's whose tables are located in other files. (I use a 3 file system.) When you say 6 data files do you also mean 6 tables. If so you might want to consider have all six tables in one file.

2. I can't answer with any authority, but I don't believe there would be any differences.

[RalphL]

I have made set of files to use the Accounts script steps in a 3-file separation model database. I think I have bugs worked out, but I am the only one who has tested it. There are 3 FM7 files and a PDF Read Me.

I would like some discussion and constructive criticism. The database is trivial, one data table, one business rules table and a globals table.

Use the Account "Developer" with the password "Master" to open the files with full access priviliges. Other accounts and passwords are displayed on layout "Basic"

[RDecker]

> 1. Why? In my interface file there are no tables.

> The layouts reference TO's whose tables are located

> in other files. (I use a 3 file system.) When you

> say 6 data files do you also mean 6 tables. If so

> you might want to consider have all six tables in one file.

I mean 6 files, most of which have multiple tables. No tables in the Interface file. There are reasons why I've selected this structure (hopefully good ones!). Yes, administration of accounts, etc. would be easier in a single file, but that's not always best.

[wider]

To RalphL

I would like to go into discussion,

but what are the passwords to open your solution? I can't find them anywhere.

[RalphL]

Ops! Sorry about that. The Account is "Developer" and the password is "Master". The main accounts & passwords are displayed in the "Basic" layout.

I guess that is not the way to get a discussion started.

[agross]

Ralph,

Just wondering why when I click on the "Add" button (or the First, Previous, Next, Last buttons) there is a momentary flash to another window and then back again. This doesn't occur with "Delete".

I am using this in Windows XP - yet to try with OS X.

Arnis

[RalphL]

It doesn't do that on OS X. The common thing here is the script Toggle Zoom. It checks for platform and behaves differently for the 2 OS's. I don't have a windows machine that run FMP 7. Please work with that script, i.e.,the adjust window steps. Lets us know what needs to be changed. Thanks.

[smorr]

The key thing to know here is that the account and passwords of all opened databases don't have to match. --

That is, if you have a backend DB opened under one account/password/privilege set, and the front end open under another, any backend table occurence in the frontend database will use the privileges that the backend database is currently openned under -- NOT the privileges that the frontend is opened under. If you relogin to the backend database with different privileges, you will have those different privileges in the front-end layout that draws from the backend database.

The implication of this is that the user accounts only need to be on the front end database.

For example

The backend databases have accounts based on privilege sets... forexample: accounts NAMED DataEntryWithDelete, DataEntryNoDelete, etc, each with its own concordant privilege set (no need to have multiple accounts for any given set).

In otherwords: every PRIVILEGE SET of the front end database is a USER in the back end databases.

Each backend database has a script: "Re-login [account password]" that takes the accountName and the account password

on Startup the frontend database runs a login script that will call the "Re-login [account password]" in each backend database based on the user's privilege set in the front database and the appropriate password for the backend end usage set.

This way the user can set his/her password at will -- without any script that try to proprogate that password throughout the system.

Also a change of user privilege sets in the front end will mean concordant changes to user privileges throughout the system.

By the way, you should set up in each database, a startup user and password that has extremely restricted privileges (ie view new data, view only splash screen layout: run only the relogin script) set the backend database to automatically open with this restricted user.

For example:

In the frontend

JoeSmith is member of "CannotDelete" privilege set

In the backend:

There is no JoeSmith user

"CannotDelete" is a user who is a member of "PS_CannotDelete" whose record delete privilege is set to off

When JoeSmith logs into the front database, the login script gets his privilege set ("CannotDelete") and calls the back-end's "Relogin" script with parameter "CannotDelete supersecretpassword". You can have the same supersecretpassword for each of the backend user/privilege sets (not as secure) or 2) use an if else ladder in the login script supplying the appropriate password parameter for each privilege set -- ok for few privilege sets or 3) set up a table in the frontend database that associates the privilege sets with the backend password (just make sure only the full access/admin users can see this)

What if you want to set backend privileges based on account names?

If you want to set a privilege in the backend contingent upon the account name (eg edit only own records) of the logged in user (int the frontend) then build a relationship in the backend to the front end to get the user logged into the front end.

in front end:

make calculated field "CurrentAccount" = get(accountName) (do not store) in a table, say "Globals"

create a global relationship from backend to frontend "Globals" table

In the back end create a user: "CanEditOwn" who is a member of "PS_CanEditOwn" which has the record level control set to edit only own records. ie edit only when field recordcreator = Globals::CurrentAccount

If you were to have an accounts table you could actually associate different privileges in different backend databases by user

For example:

JoeSmith has privileges of "CannotDelete" in Personnel database

JoeSmith has privileges of "CannotView" in Salaries database

SallyBrown has privileges of "CannotDelete" in Personnel Database

SallyBrown has privileges of "CanView" in Salaries database;

SallyBrown has privileges of "Full" in budgets database;

When JoeSmith logs in, the script finds his records from the account table and logs into Personnel as "CannotDelete", then logs into Salaries as "CannotView" and does not log in to the budget database.

When SallyBrown logs in, the script finds her records from the account table and logs into Personnel as "CannotDelete", then logs into Salaries as "CanView" and logs into Budgets as "Full"

Scott

LoginExample.zip

[Deep Thought II]

hmm... one question, what happens to the backend database's "currently logged in user" if say, there are 3 or 4 different users with different privileges sets if as each user with a specific privilege logs on, the backend database relogins itself?

[smorr]

hmm... one question, what happens to the backend database's "currently logged in user" if say, there are 3 or 4 different users with different privileges sets if as each user with a specific privilege logs on, the backend database relogins itself?

I am not sure what you are asking here, but I don't see any problem -- the user is relogging in on his/her machine. I would assume one machine, one user. The other machines are logged in independently of this. The key thing is that I have the global relation back to the front end so that the backend can get the current user of the frontend through a calculation)

Other users currently logged in should not be affected. (In my situation, there seems to be no affect -- I have 4-5 users logged into my backend at the same time (as "regularuser"), and there is no problem we me relogging in as "developerPrivileges" into the backend)

The offshoot of this though is probably the fact that server logs will show "privileges" logged in, not "users".