Possible to implement privilege set security in table based login via PHP?

[soulicious]

Hello FMP security experts! 

Is it possible to lock down records "per user" in a database that is accessed via a PHP web interface that uses a table based login (as opposed to an "Account based" login)?

The database needs to allow for multiple users who can only access their own records.  This is no problem with an account based solution where the concept: Get(AccountName) = RecordOwner  is used within the privilege set to only allow the active user access to his/her own records.  However, since this solution needs to scale to around 100 users, I considered using a table based login in order to ease account management for that many users.

The problem is that since the table based login uses a single "default" style login, let's call that login "webuser", if I use Get(AccountName), it's not actually reflective of the user actually logged in!  I just can't seem to get my head wrapped around this.   I tried using a field called "AccountName" in the User table so that AccountName = RecordOwner could still be used for the privilege set security setting, but since the records are always related to the AccountName of the user that created them, this equation (AccountName = RecordOwner) always rings true and allows for all records to be viewed by everyone logged in. 

The unique factor in the Get(AccountName) security paradigm is that the active "Account Name" might not be the same as the Record Owner name which allows or disallows access.  However, using a field in the User table creates a scenario where if that User and their records are related, they are always related.  I haven't been able to come up with a way to say: if the user is "webuser", then make the current account = the actual active account.  Then use this info to limit viewing within the privilege set.

Is this scenario even possible at all using PHP with table based logins?  If not, I'll stop trying, lol!  If it is, I need some help seeing how to do it.

One last question, even if it is possible to do this via table based logins, should I be using Account based logins anyways?

Thanks in advance for your help! 

[doughemi]

A Table-based login is a big security risk.  Don't do it! Use FileMaker's built-in account structure, or use External Authentication (which uses OS level authentication which is passed  to FM).

Account creation, deletion, activation and deactivation are easily scripted. Allow one or more gatekeeper accounts access to these scripts.  I have solutions with thousands of accounts that work fine with PHP users.

[soulicious]

Thanks for the response Doug.  I went ahead and converted my project to be account based, but now it seems I have a new problem...

Converting to account based access works well in Filemaker.  I have the privilege set calculation set to Get(AccountName) = RecordOwner and when I log in to FileMaker it does as expected: the account owner can only see their own records.  All other records are viewed as <no access>.

However, when I log in to the web interface, it doesn't find any records anymore; even if I log in as administrator.  If I "echo" the $_SESSION info, I find that it is recognizing the correct account as being logged in.  Not sure where I'm going wrong...

Any help is appreciated!

[doughemi]

The first place to look is in your FileMaker PHP API login credentials:

define('FM_HOST', 'YourHostURLorIP');//your host info
$fm_file = 'YourFileName';
$fm_user = $YourUserName ;//is this still your generic web username?
$fm_pass = $UserPW ;

include ('FileMaker.php');
# instantiate a new FileMaker object
$fm = new FileMaker($fm_file, FM_HOST, $fm_user, $fm_pass);

If that's not it, post your PHP code.

[soulicious]

Thanks Doug. 

It seems before I tackle the account security issue, I have to get my login situation fixed.  Even though I switched to the account based login (as opposed to table based), it is actually still logging in via the table.  I've verified this by trying to login as a user defined in the accounts where my login is rejected.  However, when I add that user to the user table, the login works.

Back to the drawing board... but hopefully fixing the login issue will also solve my account security issue!

[soulicious]

Just wanted to quickly report back in order to "close" this thread.  Everything is working as expected now!  I "reset" my connection to the FileMaker server by "re-installing" the PHP API and got back to logging in via filemaker accounts (instead of a table login).  Now the privilege set security is working!

Thanks again for your time, Doug!

[Steven H. Blackwell]

A general comment here.

 

In all modern versions of the FileMaker Platform what is called the Unified Security Model provides for the authentication of all Accounts when connecting from any client, including Custom Web Publishing, WebDirect™, FIleMaker GO, and FileMaker Pro. Either internal file Accounts or External Server Accounts may be utilized, including those housed in Active Directory, Open Directory, or Local Security Groups on the FIleMaker Server machine.

Single Sign-On is supported for Windows OS clients connecting to Windows Server OS machines running FIleMaker Server when those Accounts come from Active Directory.

 

Steven

[James Gill]

Is there a white paper on how to implement a non table-based login system for FileMaker?  I'm so dang used to having a record in a table represent a 'session' that the whole concept of using FileMaker-based security alone to control what a user can and can't see is a little foreign. Or maybe I'm confused as to what exactly is meant by 'Login based' authentication?  I'm about to step into the world of WebDirect for a rather large implementation and want to make sure that security is up to snuff.

My users connect to the Web Direct database via the [Guest] account and are restricted to just the login layout and a few necessary fields and tables while authenticated as [Guest].  Once they have successfully provided their username and password to their account (Accounts are stored within FileMaker's own security preferences and referenced via an Accounts table that stores passwords (hashed), usernames, emails, etc) and re-logged into their own account once the password matches the value stored in FileMaker security. I have a session table that is then set so that I can tell who's logged in and also referenced saved sessions if I need to.

Is it a security risk to use a table-based login to represent the active user session? Or am over-thinking the whole thing and the only 'worst practice' storing hashes of passwords?

Edited August 18, 2015 by James Gill

[soulicious]

Hi James,

"Account based logins" simply refers to the built in FileMaker security setup under File->Manage->Security where you can add accounts and control their access to the database very granularly via privilege sets.  The "Guest" account that you are using is one of these accounts.  You can add as many accounts as you need and control groups of their access via the privilege set.  These native "account based logins" (as opposed to table based logins) also allow PHP sessions to authenticate and connect to the database.  I'm not using webdirect (the licensing is too expensive for lots of concurrent users) so I can't speak specifically on how web direct works, but I can say that I do something similar with a user table and I keep "extra" info about users and their session in the user table.  However, it turns out that using the built in security/accounts for authentication and security gives me way better control of each user's access within my whole solution.  Since you can even use calculations in a privilege set, you can control just about anything under any circumstance!  All the "extra" user session info you need can still reside in your user table, but you don't have to rely on that table for security.

Hope that helps!

By the way, I'm from Fresno too (though I live in SoCal now).  Did you grow up in Fresno (I went to Bullard High)?  How's the FileMaker community there?

Best wishes!