Forum Discussion

davidfarje's avatar
davidfarje
Icon for Nimbostratus rankNimbostratus
Jul 04, 2024

APM Local DB multiple groups

Hi,

I'm using APM with localdb authentication and performing a group lookup and resource assign ACLs based on the localdb group. It works well with one group and one set of ACLs per group. 

But what if I want a user to have ACLs from more than one group? do I assign multiple groups to the user? I've sort of tried this but it did not work.  Only ACL from one group are applied.  Is this sort of functionality supported or is the group field in localdb meant for only one group?

  •  try adding AD query after the logon Page and then assigning the resources on the user level.

     

    try using the expression in the Advance resource Assignment and then assigned the user with individual resources.

     

    expr { [mcget {session.logon.last.username}] == "test_user" }

     

    Branching in an access policy based on local user database groups

    You can store user group membership strings in a local user database instance. You can add one or more strings for a user to the database. The strings can reflect any grouping strategy that you want to apply. You can make user group-based branching decisions in an access policy by reading the group information for the user from the database, and creating rules for branching based on it.

    Before you can perform this task, you need users and user group membership strings configured in a local user database instance. You also need an access profile.

    Task summary

     

    Creating an access policy to branch based on local DB group membership

    You can use an access policy to retrieve user group membership from a local user database instance and configure branch rules to provide different actions for users in different groups.

    1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
    2. In the Access Policy column, click the Edit link for the access profile you want to configure. The visual policy editor opens the access policy in a separate screen.
    3. On an access policy branch, click the (+) icon to add an item to the access policy. Repeat this action from the visual policy editor whenever you want to add an item to the access policy. A popup screen displays actions on tabs, such as General Purpose and Authentication, and provides a search field.
    4. Type local in the search field. Search is not case-sensitive. A list of matching actions is displayed.
    5. Select Local Database and click Add Item. A properties screen displays.
    6. From the LocalDB Instance list, select a local user database.
    7. In the User Name field, retain the default session variable or type another variable name or a user name.
    8. From the Allow User Creation list, retain the default value (No).
    9. Click Add new entry. A new line is added to the list of entries.
    10. Configure the entry to read the groups from the database and store them in a variable:
      1. From the Action list, select Read.
      2. In the Source column from the DB Property list, select groups.
      3. In the Destination column Session Variable field, retain the default value, session.localdb.groups or type the name of a variable.
      4. In the Source column from the DB Property list, select groups. You have configured an action that reads the user's groups into a variable.
    11. Click the Branch Rules tab to edit a branch rule.
    12. Click the Add Branch Rule button. New Name and Expression settings display.
    13. In the Name field, replace the default name by typing a new name over it. The default name is Branch Rule n where n is a number. The name appears on the branch in the access policy and so should be descriptive.
    14. Click the change link in the Expression area. A popup screen opens.
    15. Click the Advanced tab. Use this tab to enter Tcl expressions. A text input field displays.
    16. Type an expression into the text input field. If you expect groups to include only one entry, you can type an expression similar to this one.expr { [mcget {session.localdb.groups}] eq "eng" }If you expect groups to include multiple entries, you can type an expression similar to this oneexpr { [mcget {session.localdb.groups}] contains "sales" }
    17. Click Finished. The popup screen closes.
    18. Add more branch rules to provide branches for different user groups.
    19. Click Save. The properties screen closes and the visual policy editor displays.
    20. Optional: Add any other branches and actions that you need to complete the access policy.

    When the access policy runs and takes the branch with the Local Database read action, additional branching is done based on group membership.

     

    Sample access policy that uses local user DB groups in a branching strategy

    Local User Database (f5.com)

    Watch this youtube Video for Local DB groups:

    https://www.youtube.com/watch?v=BCxAxH_0o7Y

    ========================

    Separating groups assigned to users in Local User DB into individual variables (f5.com)

    About LocalDB Group Lookup,About LocalDB Group Lookup,About LocalDB Group Lookup (f5.com)

    Local User Database (f5.com)

    AD and LDAP Group Resource Assign feature (f5.com)

    HTH

    ��

     

  • Hi F5_design_engineer,

    Resource assignment based on LocalDB group works.  What I want to know is, if I assign a user to multiple LocalDB groups.  Will the resource assigns for each group be cumulative? or mutually exclusive?

    • Lucas_Thompson's avatar
      Lucas_Thompson
      Icon for Employee rankEmployee

      The important thing to remember about this part of APM is that *everything* is done using session variables. APM has 2 main agents that operate on the "assigned" session variables, Advanced Resource Assign and AD Group Assign.

      Advanced Resource Assign operates like 'Evaluate each rule and run assignments based on first match". So in this regime you have to do tricks like "if a user is a member of A and B, then give them A and B resource", "if a user is a member of A and C, give them A and C resource", etc. This is fine for like up to 3 groups, but the number of rules you must have increase geometrically with the number of groups, so it's not useable for ordinary group-based assignments.

      AD Group Assign operates like 'Evaluate each rule and run assignments based on each match'. Its input source is "session.ad.<AD SERVER NAME>.attr.memberOf", which is a pipe-delimited list of AD / LDAP-ish DNs. AD Group Assign runs EACH rule and doesn't stop on the first match. The trouble comes when you want to do this with group data that's not exactly like how AD returns it. It should be possible to transform and load whatever group data you have from other AAAs into the format expected by this agent.

       

      You can of course use the "variable assign" agent to put any values you want into any session variable to modify the behavior. All session variables are just text strings, where arrays delimited by pipe characters.