"But then I read opinions stating that I've reduced the security of my solution by taking the locks off the car door and relying on the ignition key."
I would turn it around. Do the people making this statement have any basis for it, or are they just giving you their opinions?
I was the one making the car analogy, and yes; there is a basis for it. It's kinda obvious too: once you let a user in, they are in and have more attack vectors than someone that is still trying to get in.
Whether it is something you need to worry about depends on the value of the intellectual property of the solution, the value of the data, etc.
How does that apply to the practice of an opener file with minimal privs, followed by a login?
The reason I ask is, if I understand the question correctly, the application in question uses a local file on iOS to access a hosted file on Server. To configure such a local file correctly, the auto-login should have only very minimal accesses - just enough to get logged in and request credentials. The local file should be almost a "dummy" file with very little in it.
Or am I missing something?
What you are describing though is a combination of two things:
- the opener file
- and auto-login
Opener files in their simple form do not auto-enter the user in the target solution; they are just shortcuts to the hosted files and don't attempt to log the user in: the user will be prompted for credentials before the target solution gets opened.
In your scenario, you are combining the "shortcut" with "auto-login". It's the auto-login that puts the user inside the file without a challenge. The scripted challenge comes after they are already in.
To configure such a local file correctly, the auto-login [...]
This part is not correct. There do not need to be any credentials in the local file that also exist in the target solution. The local file can auto-login with the default admin account for all we care, because it just serves to make the initial connection to the hosted file. When FM Go attempts to open the hosted file the user will be asked for credentials. The target solution does not need to also auto-login for this mechanism to work.
Not missing anything Mike, that's what it is. The iOS file has layouts and scripts but no data (except the "global" master). Login to that is automatic. A trigger script is run which captures user/pass and then calls a re-login on the hosted file. If an error (212) is generated on the host, the iOS client either closes or gives you another go, depending on how you script it.
Obviously the auto login on the client has minimal privileges.
Wim's concern comes with whether or not the auto-login account in the local file also exists in the hosted solution. He is correct; this is a definite no-no. You can have an auto-login if you like (to avoid users having to log in twice); just make sure you don't use an auto-login to an account that actually exists in the database.
This also applies, as Wim noted, to opener files.
Now that I understand what's going on ...
Hmm, just to be clear, the initial login to the client is an account with a username that does not appear on the host, not even with minimal privileges, because that gets them into the car? That's what I have atm.
Let's back up a second here. It was my suggestion originally, and I don't see what's wrong with it.
The original question is complicated a little by the separation model, but the issue Mike and Wim seem to having is with the "Log in using..." in the File Options.
My suggestion is to have an account in the hosted file set to log in automatically. Let's call it username "login". With no password. Yep, sounds scary. But that account's privilege set would be permitted to access no layouts, no value lists, no records, and only a single script: Re-login. That "Relogin" script would be set to run On First Window Open and would have the Re-login script step and some error handling for bad attempts.
What is the actual security hole here?
*Please note, the actual solution I suggested was to have this separated, and have the re-login on the client, capture the credentials in Custom Dialog globals and pass those to the host for login. Rethinking it, I'm not sure if that's even possible without having the host credentials in the client file or triggering the host's native login.
Message was edited by: DavidJondreau
Correct. Use their “real” account to log into the host. The local database doesn’t have to demand a login; it can use a default account with minimal privileges that doesn’t exist on the host. But you don’t want someone accessing the hosted database without presenting credentials.
But you have to open the host file to be able to use the re-login script, otherwise you're back at the beginning, losing control of the login process and leaving it to FM which means being re-presented with logins? Presently my clients don't seem to notice whether they're being preented with a dialogue for teh Client or teh host, and frankly I don't think they care. But what happens after a disconnect is that they're presented with a login to the client and when they (blindly) use their host credentials and are refused, they call me. I've got into the habit of one-word responses, like"re-boot".
What option is there but to open the host file with another dummy login with privieges set to only allow access to the one "re-login" script?
Okay, now I'm confused. What exactly are we trying to accomplish? Such a scheme just mimics logging into the file, doesn't it?
You have to trigger the host's native login, I've tried it.