1 2 Previous Next 18 Replies Latest reply on Sep 16, 2013 1:20 AM by brianrich46

    Duplicating the Read-Only Access privilege set

    brianrich46

      I'm working with FMP11 on Windows and have over 90 legacy databases hosted on an FMP11 Server Advanced. I've been investigating if we can migrate from Filemaker Authentication to External Authentication. One major issue is that the privilege sets created for these databases have not be implemented consistently by previous developers. Although the account names used are consistent - e.g. each database has an account for ENG, SALES, QUALITY etc. - in one database the ENG account might use the privilege set 'Privilege Set 3', and in another ENG might use [Read-Only Access] - both cases giving the ENG account an appropriate level of privileges. We thought the easiest way to move to EA would be to create a new set of EA based accounts matching our current Filemaker accounts which linked directly to our Windows Security groups, and provide a parallel set of privilege sets which were copies of those used by the Filemaker Authenticated account. This would allow us to migrate users progressively by the simple expedient of adding them to the appropriate Windows Security Group when we were ready.

       

      However, this didn't work where any Filemaker account used the [Read-Only Access] privilege set - any EA account linked to a duplicate of the [Read-Only Access] set kept throwing access privilege errors. It appears that duplicating the [Read-Only Access] privilege set does NOT give you a new set with the same privileges, as users of the duplicate set cannot edit global fields by default, something they can do if they are using the [Read-Only Access] set. The problem is that if [Read-Only Access] can't be duplicated to allow users to edit global fields, we'll have to edit the copy in almost every database to allow users to edit their global fields.

       

      I've not been able to find a reference to this issue elsewhere, though I am told that it is 'a known issue'. Do copies of the other default privilege sets exhibit similar discrepancies? Has anybody come across this problem before, and do they have a simple solution?

       

      Thanks

       

      Brian

        • 1. Re: Duplicating the [Read-Only Access] privilege set
          Mike_Mitchell

          Brian -

           

          I'm not sure I understand why would you need to duplicate a privilege set. You can assign whatever accounts you want, as many as you want, to any given privilege set.

           

          Mike

          • 2. Re: Duplicating the [Read-Only Access] privilege set
            brianrich46

            Hi Mike

             

            Two reasons -

             

            • the [Read-only Access] default set allows the user to change the account password and you can't alter that. We have many separate databases with over 50 users so want prevent that possibilty where FM authenticated accounts use that privilege set by turning off the change password privilege in the duplicated set.
            • The recommendation when setting up EA is that you create role-based accounts with corresponding privilege sets. The simplest way to do this in a legacy system is to duplicate the current privilege set, naming it to match the role of the corresponding account. Unfortunately, previous developers made liberal use of the default privilege sets, most often the [Read-Only Access] set, and it was when we started to duplicate this set we found the problem - took a while to work out that it wasn't caused by using EA accounts.

             

            The issue is that if the [Read-only Access] default does not apparently duplicate correctly - we have hundreds of globals scattered through our legacy databases and having to fix up every duplicate of the set to allow user editing of their globals is a major job. It's do-able but significantly changes the scale of the work required.

             

            Thanks

             

            Brian

            • 3. Re: Duplicating the [Read-Only Access] privilege set
              Mike_Mitchell

              You don't have to duplicate a privilege set to duplicate an account's role. You can assign multiple accounts to the same privilege set. I realize you're doing that for housekeeping reasons (i.e., to make it easier to keep track of), but it's unnecessary. So what if the internal FM accounts use the same privilege set as the EA accounts? They have the same privileges anyway. You're making extra work for yourself and creating the issue you want advice solving,

               

              So here's the advice: Assign the same privilege set to the internal FM and external EA account. When everyone has been moved over to the workgroups, delete the internal accounts.

               

              Example: Bob (Accounting), Jim (Sales), and Cindy (Sales) all have separate accounts. Bob is assigned to a specific privilege set called Priv Set 3. Jim and Cindy are assigned to . Create two new EA accounts called ACCOUNT and SALES. Assign Priv Set 3 to ACCOUNT and to SALES. As soon as everyone is assigned to the correct workgroups, delete their individual accounts.

               

              If you don't like the fact that isn't very descriptive of SALES, you can just create (not duplicate) a new privilege set called "Read Only - Sales" with the same capabilities. But the security model is designed to have only one privilege set for each set of capabilities, not for each account. If Sales, Marketing, and Clerical all have exactly the same capabilities in the database, they should use the same privilege set, not different sets that are functionally identical. When the documentation describes "corresponding" privilege sets, they're not talking about privilege sets corresponding to every account. They're talking about privilege sets corresponding to what every account's roles or functions should be.

               

              The mantra for the security model is this: Accounts describe WHO can get into the database; privilege sets describe WHAT they can do once they're in.

               

              HTH

               

              Mike

              1 of 1 people found this helpful
              • 4. Re: Duplicating the [Read-Only Access] privilege set
                brianrich46

                Hi Mike

                 

                Thanks for that helpful input.

                 

                Assigning the same privilege set to the FM and EA accounts is possible, but in many cases one of the default privilege sets is currently assigned to the FM account. The advice I have is NOT to use these default sets at all but to create new ones. Duplicating the set rather than building it from scratch seemed the logical way to go to save time and ensure consistency with the present privilege sets.

                 

                The end result of the exercise is to establish a consistent set of privilege sets which exist across all 94 of databases. Thus if I want to determine what users logging in with the SALES account can do in any of the databases, I look for the Privilege set called P_SALES. For example, the SALES account login in the Reject Notes database uses the [Read-Only Access] privilege set.  In the Order Tracking database, the sales account uses the privilege set Production Staff.  If I (could) duplicate [Read-Only Access] in Reject Notes and call it P_SALES, and I duplicate Production Staff in Order Tracking and call it P_SALES then move the SALES accounts in both databases to the P_SALES privilege set, I've started down this path.  At some point in the future, when all the role-based accounts Production, Sales, Engineering, Accounts, QA, Manager, HR - which presently exist - have a corresponding privilege set P_Production, P_Sales, P_Engineering, P_Accounts, P_QA, P_Manager, P_HR and the accounts have been linked to their role based set, I'll go back and delete any privilege sets that are no longer required.  I think this follows your mantra.

                 

                However, what appeared to be a relatively simple task which should be achiveable by just duplicating current sets and renaming then is compromised because I can't 'duplicate' [Read-Only Access] directly.  Once I've duplicated it, I then have to go through every table in the database and customise the global fields to allow user editing so I can achieve the same privilege levels as [Read-Only Access] has by default. Yes, I can do that but it makes the job a lot more complicated and time consuming.

                 

                I'd also like to find out if duplicating any of the other default sets has similar limitations, but I can't find any information about the problem.

                 

                Thanks

                 

                Brian

                • 5. Re: Duplicating the [Read-Only Access] privilege set
                  Mike_Mitchell

                  The advice I have is NOT to use these default sets at all but to create new ones.

                   

                  From who? If the defaults do what you need, I see no reason not to use them.

                   

                  Thus if I want to determine what users logging in with the SALES account can do in any of the databases, I look for the Privilege set called P_SALES.

                   

                  Again, you seem to be stuck on the idea that you have to tie a priv set to the account. You do not have to do this. In fact, that's the whole purpose for separating privilege sets from accounts in the first place (which happened way back in FM 7).

                   

                  At some point in the future, when all the role-based accounts Production, Sales, Engineering, Accounts, QA, Manager, HR - which presently exist - have a corresponding privilege set P_Production, P_Sales, P_Engineering, P_Accounts, P_QA, P_Manager, P_HR and the accounts have been linked to their role based set, I'll go back and delete any privilege sets that are no longer required.  I think this follows your mantra.

                   

                  No, it doesn't. Not if P_Production and P_Sales (for example) are identical. You're just creating extra overhead. You have to maintain extra, identical, priv sets for no real benefit other than just being able to say, "Oh, the one named Production = the Production account". And you can do that just by looking at the account in the Manage Security dialog.

                   

                  Look, you can do what you want. But you're making unnecessary work for yourself. For example:

                   

                  I then have to go through every table in the database and customise the global fields to allow user editing so I can achieve the same privilege levels as [Read-Only Access] has by default.

                   

                  If you just used the default priv set for all these accounts, you wouldn't have this problem. (BTW ... you can also use Extended Privileges to allow certain functions across multiple priv sets without having to customize anything.)

                   

                  Do what you want. But your determination to link a specific priv set to an account is what's causing your difficulty.

                   

                  Mike

                  • 6. Re: Duplicating the [Read-Only Access] privilege set
                    brianrich46

                    Mike_Mitchell wrote:

                     

                     

                    From who? If the defaults do what you need, I see no reason not to use them.

                    The recommendation came from Steven H Blackwell on fmforums.com - 
                    see: http://fmforums.com/forum/topic/89565-does-read-only-access-really-mean-that/

                     

                    Mike_Mitchell wrote:

                     

                     

                    Again, you seem to be stuck on the idea that you have to tie a priv set to the account. You do not have to do this. In fact, that's the whole purpose for separating privilege sets from accounts in the first place (which happened way back in FM 7).

                     

                    Do what you want. But your determination to link a specific priv set to an account is what's causing your difficulty.

                     

                     

                    I was only trying to follow what was being suggested as best practice by several people when using EA: -

                    see  http://fmforums.com/forum/topic/89356-migrating-to-external-server-authentication/

                     

                    Thanks

                     

                    Brian

                    • 7. Re: Duplicating the [Read-Only Access] privilege set
                      Mike_Mitchell

                      You ignored what Wim told you:

                       

                      "You don't need to set up one Windows domain group per existing FM account, but rather one Windows domain group per existing privilege set."

                       

                      That's exactly what I'm trying to tell you, only in reverse. Accounts can share a privilege set. What Wim is telling you is that, since a privilege set defines a role, you can group all the accounts that use that privilege set together into a group. Using the same privilege set. (That is, no need to duplicate a privilege set!)

                       

                      As far as Steven Blackwell's recommendation not to use the defaults ... I respect him, but I consider him to be a little overcautious.

                       

                      Regardless, you can create a new priv set that does everything the default does in about 15 seconds, so I don't think that's a significant burden. If you're really worried about it.

                       

                      But you should not have more than one privilege set in a database that has the same capabilities. It adds to your maintenance headaches and confuses your role management.

                       

                      Mike

                      • 8. Re: Duplicating the [Read-Only Access] privilege set
                        Mike_Mitchell

                        Maybe this will make it more clear:

                         

                        A "role" is not a department, or logical grouping of people in your company (like Procurement, or Sales). A "role" is a collection of permissions that a user has inside the database. So if, for example, Susie from Sales and John from Procurement have the same exact permissions inside the database, they have the same role. The fact that they work for two different departments is irrelevant.

                         

                        Does that help?

                         

                        Mike

                        • 9. Re: Duplicating the [Read-Only Access] privilege set
                          DavidJondreau

                          Mike is right that accounts are for people, privilege sets are for roles. The only reason I can see for having separate, identical privlilege sets is that you may want to change their settings in the future. But even if you get that straigthened out, with 90 files, you've still got a lot of work ahead of you. I'm not sure what you're larger plan is here, but you should consider consolidating those 90 files into just one data file (or maybe several). You can keep your separate files for interface purposes for now. But that consolidation would make resolving these security issues a lot simpler.

                           

                          I've never heard of creating a custom privilege set to allow access to global fields in the context of Manage Security...I can see how it would b done with scripting, but not RLA.

                           

                          Finally, Blackwell does point out an issue with Read Only, but it's an issue that works in your favor! Unless we get more info, I'd just use the Read Only accounts.

                          • 10. Re: Duplicating the [Read-Only Access] privilege set
                            ch0c0halic

                            Mr. Blackwell has a very good reason for suggesting you use a duplicate of one of the default Privilege sets.

                             

                            The original default privilege sets cannot be changed!

                             

                            If you ever need to modify the access privileges for a 'role' you can't if its one of the predefined Privileges.

                             

                            Duplicating a default Privilege set may save a few minutes in defining a new one. However, I believe the default setup for a new Privilege set is also pretty close in many cases. If I am defining a series of successively restricter privileges I will duplicate the current one (not a predefined one).

                             

                             

                            A few things to think about when naming(defining) Groups, Roles, and FMP Access Privileges.

                            An External Authentication Group defines who has what Role in each solution. A group name should tell you right away what the user should be allowed to do when in the Group. But, remember that a group can be used in many different FMP solutions so be careful who is put in each Group and what the Groups Role is in each solution.

                            A Role defines how the user is supposed to interact with the data.

                            A Privilege set defines how a user interacts with the data.

                             

                            A Group can only be attached to one Privilege set (Role) but a person can be in many groups. Special care must be taken in the Authentication order of the Groups in order to provide the correct access to each user.

                            • 11. Re: Duplicating the [Read-Only Access] privilege set
                              Mike_Mitchell

                              No, you can't change the defaults. But that's hardly, in my mind, a reason to say you should "never" use them.

                               

                              If I need to change something, I can create a new privilege set in under a minute that duplicates one of the defaults and then make whatever changes I need. I'm not convinced that not being able to change the defaults is a compelling reason to scare people away from using them.

                               

                              Also, I'm not sure we should make a one-for-one equivalence between EA groups and roles. As you point out, a person can be in many groups. Similarly, different groups can share a role. For example, we often create multiple groups for different organizations (so they can control membership), yet all those groups might share the same role (for example, Guest).

                               

                              Mike

                              • 12. Re: Duplicating the [Read-Only Access] privilege set
                                brianrich46

                                Thanks to all of you taking part in this discussion. 

                                 

                                On the issue of how to define roles and implement them, I'm really no further forward as there appear to be many views on what is 'best practice' and I'm not convinced about how quick and easy this really is when you have to deal with a large number of databases.

                                 

                                Consolidation doesn't seem a good option when we are already dealing with hundreds of layouts, fields and scripts in a some of those 94 databases, and I can't imagine what the relationship diagram would look like with the all 94 databases merged into one. Restoring after a server crash would be a nightmare with all the tables in a single database, some of our tables contain half a million records.

                                 

                                On the problem of duplicating the default [Read-Only Access] set, please can you consider the following - I see the same issue in V10, V11 and V12.

                                 

                                Create a new database in the usual way.  Set up a table which contains one standard text field and one global text field and a single record and put some arbitaty text into the two fields.  Set up an second account of your choice and put it into the [Read-Only Access} privilege set. Login to the database using the second account. You should be able to change the text in the global field, but not in the standard text field, which will give you an access privileges message.

                                 

                                Relogin as admin, and duplicate the [Read Only Access] set to a new set. Create a third account and put it into the new set you just created. Relogin using the third account, and you should still be able to modify the global field as you could before.  Relogin as admin, and in the new set, turn off the privilege which allows the user to modify the password. Relogin using the third account and try to modify the global field - you won't be able to.  You would need to set the edit status of the global field to modifiable in order to give the third account back this privilege.

                                 

                                Worse still, if you go back to the new set and set the password change privilege on again, you will STILL be unable to modify the global field when logged in as the third account. I've not experimented extensively, but it looks like modifiying ANY setting in the duplicated set 'breaks' the ability of the account user to edit globals in the duplicate set and setting it back to it's original value doesn't reinstate the privilege.

                                 

                                I can't find any reference to this issue anywhere, and until I get some idea of whether it affects just duplicates of the [Read-Only Access] set, I'm reluctant to undertake a migration to EA.

                                 

                                Thanks

                                 

                                Brian

                                • 13. Re: Duplicating the [Read-Only Access] privilege set
                                  Mike_Mitchell

                                  If you're convinced that this is some sort of bug in FileMaker that needs to be addressed, then report it as such:

                                   

                                       http://forums.filemaker.com/hives/1eea103f05/summary

                                   

                                  Now, to answer your other questions:

                                   

                                  1) You're not convinced it's easier to assign multiple accounts to one privilege set instead of multiple privilege sets you have to create? What evidence could we provide that would convince you that assigning multiple accounts to a single, pre-existing priv set is easier than creating lots of new ones?

                                   

                                  2) With regard to consolidation, your final solution will be vastly simpler and less cumbersome once finished. Example: I inherited one solution that was 46 files. One script ran 150+ printed pages because of all the jumping back and forth between different files. After consolidation? 2 pages. The Relationships Graph was perhaps 20% more complex than the most complex Graph in any of the existing files. But I only had 1, not 46, to manage. And restoring after a server crash meant restoring 1 file, not 46. Oh, and just for fun ... only one set of security settings to manage. Not 46.

                                   

                                  It seems to me you're deeply invested in your current approach and really not that interested in anything other than that. In which case, submit the behavior as a bug to FileMaker and wait for the next release to see if it's addressed. Otherwise, you might want to give some of these other approaches a try. For example:

                                   

                                  Step 1: Create a new privilege set that has the same capabilities as the default [Read-Only Access] set.

                                   

                                  Step 2: Duplicate that new, non-default privilege set as many times as you want.

                                   

                                  Neither of these steps is actually needed to solve your problem, but if you persist in wanting to have a priv set for every account (EA group), this will solve your issue. Invested time: Approximately 30 seconds.

                                   

                                  HTH

                                   

                                  Mike

                                  • 14. Re: Duplicating the [Read-Only Access] privilege set
                                    brianrich46

                                    Hi Mike

                                     

                                    I think it's best that we draw a line under this discussion now. 

                                     

                                    Thanks

                                     

                                    Brian

                                    1 2 Previous Next