No matching user sets (no_matching_usersets)
A denied decision with the code no_matching_usersets means the user's attributes don't meet the conditions of any user set in the environment. This page is for developers who find this code in a decision log and need to fix the user's attributes, the check, or the user set.
What the no_matching_usersets reason means
The policy decision point (PDP) writes this code in the attribute-based access control (ABAC) part of the decision log's debug details (debug.abac). The debug details appear when Debug Mode is on.
| Field | Value |
|---|---|
code | no_matching_usersets |
reason | user '<user-key>' did not match any userset conditions. known usersets: <user-set-keys> |
support_link | A link to /errors/no_matching_usersets on docs.permit.io |
A user set (also called a dynamic role) is a group of users whose attributes meet a set of conditions. The PDP checks user sets first in its ABAC evaluation. When no user set matches, the PDP stops and reports no_matching_usersets without checking resource sets or rules.
The decision log also has a request.user object with the user attributes the PDP evaluated. Compare those attributes with the conditions of the user sets listed in known usersets.
Causes of no_matching_usersets
| Cause | How to confirm | Fix |
|---|---|---|
| The check doesn't send the user attributes that the user set conditions test. | request.user.attributes in the decision log is missing the attribute. | Send the attributes in the check. |
| The user in Permit doesn't have the attribute, or has a different value. | The user's attributes in the Directory screen or the Get user API response differ from the condition. | Update the user's attributes in Permit. |
The attribute value has a different type or case than the condition, for example the string "true" instead of the boolean true. | The value in request.user.attributes differs in type or case from the condition value. | Send the value with the type and case the condition uses. |
| No user set has conditions that this user should meet. | known usersets doesn't list a user set for this user. | Create or edit a user set. |
Fix no_matching_usersets
Send the user attributes in the check
Pass the attributes in the user object of permit.check(). For examples in each SDK, see Check an ABAC permission with attributes.
Update the user's attributes in Permit
Store the attributes on the user so every check can use them:
- Check the attributes Permit stores for the user in the Directory screen, or with the Get user API.
- Sync the user again with the correct
attributes, using an SDK or the API. See Sync users.
To define which user attributes exist, see Defining attributes.
Create or edit a user set that matches the user
- In the dashboard: open the Policy screen, select the ABAC Rules tab, and create or edit a user set. For the steps, see Define a dynamic role (user set).
- With the API: call Create condition set with
"type": "userset". For a complete request, see Create condition sets with the API.
A new user set grants nothing until a rule connects it to a resource set. After you create the user set, grant it the action in the Policy Editor.
Confirm the fix
- Run the same
permit.check()call again with the same user, attributes, action, and resource. To run the check from a terminal, usepermit pdp checkwith--user-attributes. - Open the Audit Log and select the new decision.
The debug.abac.code is no longer no_matching_usersets. If the code is no_matching_resourcesets or no_matching_rules, the user matched a user set, and the next check failed.