1 2 3 Previous Next 36 Replies Latest reply on May 14, 2014 5:40 AM by raycon

    User Account handling

    raycon

      Hi All,

       

      As a newbie, I'm swamped with the amount of differing opinion on handling solutions with large numbers of user accounts, and the security of those solutions. This issue has become even worse with the release of WebDirect, because whilst that's developing into a really useful tool for me, I have not yet found a pretty way of handling user accounts.

       

      I've spent the last three days testing a solution based on an external (iOS in this case) file which is authorised by a hosted file. The idea uses an open login to the iOS file and a "re-login" on the hosted file, and by golly I think I can make it work. 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 have a hosted file and an iOS app (and am developing a WebDirect app) which accesses the files on the host. Obviously I am avoiding both sync problems (I must for this client) and having to update the iOS device every time a user or permission changes on the host.

       

      Is there a resource somewhere which explains in simple terms the best practice for security in this situation? Google can't seem to find one for me.

       

      Or, more correctly, I can't find a resource, so can someone point me at the best one?

       

      Cheers,

       

      Ray

        • 1. Re: User Account handling
          Mike_Mitchell

          "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?

          • 2. Re: User Account handling
            wimdecorte

            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.

            • 3. Re: User Account handling
              Mike_Mitchell

              How does that apply to the practice of an opener file with minimal privs, followed by a login?

              • 4. Re: User Account handling
                Mike_Mitchell

                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?

                • 5. Re: User Account handling
                  wimdecorte

                  Same.

                   

                  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.

                  • 6. Re: User Account handling
                    wimdecorte

                    Mike_Mitchell wrote:

                     

                    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.

                    • 7. Re: User Account handling
                      raycon

                      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.

                      • 8. Re: User Account handling
                        Mike_Mitchell

                        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 ...  

                        • 9. Re: User Account handling
                          raycon

                          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.

                          • 10. Re: User Account handling
                            DavidJondreau

                            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

                            • 11. Re: User Account handling
                              Mike_Mitchell

                              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.

                              • 12. Re: User Account handling
                                raycon

                                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?

                                 

                                 

                                • 13. Re: User Account handling
                                  Mike_Mitchell

                                  Okay, now I'm confused. What exactly are we trying to accomplish? Such a scheme just mimics logging into the file, doesn't it?

                                  • 14. Re: User Account handling
                                    raycon

                                    You have to trigger the host's native login, I've tried it.

                                    1 2 3 Previous Next