1 2 3 Previous Next 32 Replies Latest reply on Nov 4, 2015 5:17 AM by jormond

    Is there a way to make Privilege "Subsets"?

    ninja

      Howdy to all,

       

      Before making an improvement suggestion to FMI, I figured I'd check to see if I'm just missing something.

       

      In a given solution, there may be many tasks that can be done.

      For an Inventory Management solution for example, there may be:

      - Raw Material Storage

      - Raw Material Dispensing

      - Work in process tracking

      - Finished Goods Storage and dispensing (removal for shipping)

      - Cost of inventoy tracking and accounting

      - Purchase and receipt of raw materials

      - etc., etc.

       

      In a company of large enough size, each of these tasks may be discrete operations by individuals or departments, each of which have their own privilege set that covers their tasks.

      But then comes cross training:

      - Raw Mat storage employee is cross trained to purchasing for restocking

      - Finished goods operator cross-trained to Dispensing

      - endless combos...

       

      One way to handle it is to have different account names for the same employee for the different tasks. This gets onerous.

      Another would be to make privilege "subsets" that could be assigned to an account rather than to dig into permission settings for multiple tables and layouts and scripts every time someone gets cross trained.

       

      So: Is there a way to assign what would essentially be multiple privilege sets to a single account?

      I don't think so...so the question really is whether anyone has found an efficient way to handle the endlessly changing privilege set needs when employees are cross-trained?

        • 1. Re: Is there a way to make Privilege "Subsets"?
          taylorsharpe

          FileMaker privilege sets are single item sets.  They may be a group from an Active Directory tree.  But they are each distinct and there is no such thing as one being a subset of another.  But there is also no limitation on how many you can create if you need specialized groups like "MFG" and "RAW MATERIALS", and a cross set called "MFG and RAW MATERIALS" or however you want to combine Active Directory groups based on FIleMaker privilege sets. 

           

          It sounds like you might want to do some reading up on how Active Directory (or Open Directory) works regarding management of User ID's across a network. 

          • 2. Re: Is there a way to make Privilege "Subsets"?
            ninja

            <snip>  But there is also no limitation on how many you can create if you need specialized groups like "MFG" and "RAW MATERIALS", and a cross set called "MFG and RAW MATERIALS" or however you want to combine Active Directory groups based on FIleMaker privilege sets.  <snip>

            Understood...I have all three of those sets already (and about 140 others).  But the combos are nearly endless.  The limitation is time.

             

            As I was making yet another combo today as a result of further cross-training, it occurred to me that it would be a three minute job if I could just assign a single account "The stuff RawMatDispense needs", "The stuff shipping needs" and "The stuff production oversight needs" as three functional privilege sets.

             

            Instead, I had to start with an existing combo of the first two of them and then add the third function step by step, table by table, script by script to mimic an already existing set for production oversight only.

            Having the functional subsets that I could simply assign to a user would be so much easier.

             

            You answered my question, though, which is "No, you cant do that functional subset thing"...and I appreciate your response.

            • 3. Re: Is there a way to make Privilege "Subsets"?
              wimdecorte

              Eric Twiname wrote:

              Understood...I have all three of those sets already (and about 140 others). 

               

              When I read this a big red flag came up.  Do you really have 140+ different roles in the database?  Not in the organization, but in the database.  There does not need to be one priv set for each organizational role / group.   There probably needs to be one externally managed ACCOUNT for each of those 140 organizational groups, but I doubt that there are 140 unique authorization combinations for the database.

               

              Don't confuse authentication (who are you = the acount), whith authorization (what can you do = the priv set).

               

              If you make a matrix with those 140 groups as rows and all the possible tasks in the system as rows and in each intersection mark a Y or N if that group is allowed to perform the action then it is very likely that you will see lots of common ground between those groups and end up with a number of priv sets that is only going to be a fraction of the number of groups.

              • 4. Re: Is there a way to make Privilege "Subsets"?
                jormond

                I think that works a lot of time. But from reading the OP other posts, it feels like groups of people have access to various "modules" within the solution, or at least only a subset of the records and/or features. Maybe I am reading into to it to much.

                 

                Often in web solutions, you end up seeing roles for a user. That determines what the user can and cannot access. You can add/remove roles for a specific user, or set a default set of thoes roles based on the user type. This is one area that I wish ExecuteSQL performed just a touch faster, because then you could store the role feature set in a table and query the table to see if that user has access to perform the selected task. I suppose you could still do it, using Global fields, but it's not as dynamic and I'm very wary about tying security/privileges to Global fields.

                • 5. Re: Is there a way to make Privilege "Subsets"?
                  ninja

                  I think Josh got it well...there are modules within the solution.  There are even multiple roles within a single module.

                   

                  I just did a quick list of fully discrete "roles" for users...just the ones that came immediately to mind (I left out many):

                  Dispense from room 1

                  Dispense from room 2

                  R&D producttype 1

                  R&D producttype 2

                  Manufacturing Producttype1

                  Manufacturing Producttype2

                  Room 1 material management

                  Room 1 reorder & purchase

                  Room 1 receive

                  {add for room 2}

                  Rawmat cost application Room 1

                  Rawmat accounting

                  WIP/Finished goods accounting,

                  etc. 

                  My quick list comes to 20 roles (not all shown here).

                   

                  Combining these goes to 20-factorial possible combo options (or 2.4 * 10E18 potential combos)  140 sounds pretty good so far.

                   

                  The idea of using a table has significant potential...I hadn't thought of that one.  But I, too, am not too keen on managing the security based on values in a table.

                   

                  The idea from Taylor Sharp also has a lot of potential (I think)...it's an area where I haven't played before, so quite a bit of learning is involved...and it, too, pulls privilege set management outside of the solution.

                   

                  Wouldn't it just be nice to have privilege subsets within the architecture of FMP itself?  I will suggest it and see what the future holds.

                  • 6. Re: Is there a way to make Privilege "Subsets"?
                    DrewTenenholz

                    Eric --

                     

                    If you really need to control which USERS have certain privileges within your system instead of which PRIVILEGE SETS have certain privileges (sorry for the linguistic confusion), then I'd suggest setting up a table with user names and a field for each individual user's abilities formatted as a return-separated list.

                     

                    As Josh suggested, one can use a global field to capture up the current user's current abilities at login, But you can also set up a relationship between all tables and the user table based on the user name/user ID to check for the user's ability to do something within the system.  If you base it on a stored field and a live lookup, then any changes you make are immediately reflected for the user.  Global fields scoped to the user would require some sort of update or logout.

                     

                    It's a bit of work to set up initially, but is pretty useful in the end. If you take the time to also make it a way to add FileMaker-based authentication accounts, then it is pretty re-useable for other systems as well.  You should take a look at what Get ( AcocuntName ) returns when using external authentication; I think you'll be glad to see that you can use EA and still get back a specific account name.

                     

                    I find that this is the easiest way to allow workers to 'cover' for a person who is absent/on leave where revoking their abilities is expected.  Going through the Manage>Security for every field/table/file is much harder, as you point out.  If you have this user table, then it should be just one run through the Manage>Security to set up a calculation to allow/deny access based on a FilterValues() of the user's current privileges.

                     

                    This does sort of make external authentication less useful, in that you will always need a user record in the system before the user can actually work, but it adds back the flexibility the account/privilege set/extended privileges model which is currently available does not provide.

                     

                    -- Drew Tenenholz

                    • 7. Re: Is there a way to make Privilege "Subsets"?
                      wimdecorte

                      Eric Twiname wrote:

                       

                      I think Josh got it well...there are modules within the solution.  There are even multiple roles within a single module.

                       

                      I just did a quick list of fully discrete "roles" for users...just the ones that came immediately to mind (I left out many):

                      Dispense from room 1

                      Dispense from room 2

                      R&D producttype 1

                      ...

                      WIP/Finished goods accounting,

                      etc. 

                      My quick list comes to 20 roles (not all shown here).

                       

                      Combining these goes to 20-factorial possible combo options (or 2.4 * 10E18 potential combos)  140 sounds pretty good so far.

                       

                       

                      I obviously do not know enough about your business model and the solution at this point buf if were going through this excercise together during specs gathering / business analysis, I would push very hard on this topic.  There simply are not 2.4 * 10E18 distinct roles for the database - not even 140 - that need to translate into their own priv set.  There is a conceptual glass ceiling to break through here.

                       

                       

                      Eric Twiname wrote:

                       

                      The idea of using a table has significant potential...I hadn't thought of that one.  But I, too, am not too keen on managing the security based on values in a table.

                       

                       

                      That is a common practice but I do have to warn against it - storing security info as pure data and rolling your own security schema almost always ends up being less secure than sticking with the native security model.

                      • 8. Re: Is there a way to make Privilege "Subsets"?
                        Mike_Mitchell

                        Is it feasible to use extended privileges for your "roles"? You could then test for the presence of the specific "role" through Get ( AccountExtendedPrivileges ) (or Get ( CurrentExtendedPrivileges ), as appropriate) before allowing access to a specific function or feature.

                         

                        Just a thought.

                         

                        Mike

                        • 9. Re: Is there a way to make Privilege "Subsets"?
                          DavidJondreau

                          I don't see that reducing the number of privileges sets since Extended Privilieges are part of a Privilege Set, not an Account.

                           

                          I think the issue is whether or not all of Eric's roles need to be defined in the *security* schema. I suspect not. It's certainly the most secure way, but security often murders convenience. Does it really matter if a person has the ability, at the security level, to perform a task or access data that they shouldn't? Is it just a matter of user management or are there real concerns (HIPAA for example).

                          • 10. Re: Is there a way to make Privilege "Subsets"?
                            LyndsayHowarth

                            Yes... precisely,

                             

                            The privilege sets do not have to do all the work... or it makes a lot more work for you. I bet there are only 2 or 3 P-sets you need.

                             

                            A user access table can be used in conjunction with a privilege set to only show those functions / layouts etc to which the user has the access turned on for.

                             

                            - Lyndsay

                            • 11. Re: Is there a way to make Privilege "Subsets"?
                              Mike_Mitchell

                              Not so sure. He mentioned cross-training. A person who has privilege set A normally ends up having to do a function normally assigned to privilege set B. You can set up your extended privileges so function X is attached to both privilege sets, but function Y is not. So if both privilege sets need to perform the same function, they can.

                               

                              In other words, extended privileges cut across the privilege sets, removing the need to create a new privilege set that can do some of the functions of a "parent" privilege set. Or, in Eric's vernacular, a "subset". So, it does, in a way, eliminate the (perceived) need for extra privilege sets by giving you extra granularity.

                               

                              Of course, that does mean that, at the privilege set level, both privilege sets need to have access to the necessary fields, layouts, etc., to perform the functions, so they need to be sufficiently able. But you can easily switch extended privs on or off as needs change without having to create new accounts or priv sets.

                               

                              I think Wim's caution deserves attention, too. If you were to matrix down these "roles" against exactly what permissions are needed in the database, how many true sets of privileges do you wind up with? Probably fewer than you might at first suspect, and that makes it even more likely you could manage things this way.

                               

                              Not having seen exactly what he's doing, I can't say for certain, but I've had success with exactly this sort of thing - where users with different privilege sets need access to the same function. But then I could just be whistling "Dixie".

                              • 12. Re: Is there a way to make Privilege "Subsets"?
                                DavidJondreau

                                I'm not sure I see what you mean. Person A may do function B, but what about Person A.2 also with Privilege Set A who doesn't do function B? And when using Extended Privileges, are you restricting access at the RLA level or at the script level? Does (can?) Get ( AccountExtendedPrivileges ) live in the RLA calculation?

                                 

                                I don't see how you get around needed a privilege set for each role, extended privileges or not though if it lives in RLA, I can see how EP may make it easier to configure a Privilege Set. If it script managed, then the user still has RLA access to stuff they shouldn't, which is a question that needs answering: Do these roles need to be managed at the RLA level or not?

                                • 13. Re: Is there a way to make Privilege "Subsets"?
                                  Mike_Mitchell

                                  To answer the question, yes, I believe you can embed the Get ( xExtendedPrivileges ) function in the record-level access calculation.

                                   

                                  But I'm not sure I agree that a user necessarily has "access to stuff [he] shouldn't" if you control access to an automated function - a script - with a call at the head end to his extended privileges. If he can't run the script, then he can't run the script. Whether he has record-level access is a separate topic. (Is that where you're wanting to go?)

                                   

                                  That aside, I didn't see that we had different individuals inside the same priv set who were being cross-trained. Assuming that's what Eric needs, then it does throw an additional complication into the works. You would have to authenticate to a different priv set at that point because, as you pointed out, the machine would have no way of distinguishing between two individuals with the same privilege set.

                                   

                                  But again - how tight do these privilege sets really need to be? I've taken over databases from people that had 12 or 13 priv sets in them that, upon examination, only differed by a single variable (like the ability to print). When pressed, they admitted that they really didn't need that difference and could live with something more like 4 or 5. I'm going to agree with Lyndsay and Wim - I think some pushback is called for here. Otherwise, the maintenance headache - and potential for error - is enormous.

                                   

                                  Mike

                                  • 14. Re: Is there a way to make Privilege "Subsets"?
                                    Stephen Huston

                                    I agree with the general tone of recent responses that creating appropriate priv sets is preferable and probably easier in the long run to having a user table and manually setting a variety of privs there. FMP's built in priv set security is also a lot more secure and reliable than a starting down the Rube Goldberg Road.

                                     

                                    One thing you can do to simplify some of the joy of building multiple priv sets is to get the basic priv set the way you want it, then just duplicate it and assign a custom extended priv, which can be as simple as a number.

                                    Then you can have a script which tests for

                                         If [ GetAsNumber ( Get ( AccountExtendedPrivileges ) ) < (your security test number here) ]

                                              Exit Script

                                         End If

                                    That will exit the script if the user doesn't have a high-enough security setting.

                                    1 2 3 Previous Next