> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
This page describes how to use filters with OIDC or LDAP managed groups. It assumes that you are familiar with the Boundary's general filter syntax as well as [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) or [LDAP](https://ldap.com/ldap-specifications/).
The specific content of the claims is unique to the IdP, besides any claims that are part of the OIDC specification.
We provide some examples in this section using sample claims.
Refer to your IdP for the specific syntax.
Example JWT claims:
<CodeBlockConfig hideClipboard>
```json
{
"iss": "https://server.example.com",
"sub": "24400320",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"auth_time": 1311280969,
"custom": {
"department": "infosec"
}
}
```
</CodeBlockConfig>
Example UserInfo claims:
<CodeBlockConfig hideClipboard>
```json
{
"roles": ["user", "operator"],
"sub": "alice@example.com",
"email": "rabbithole@example.com",
"name": "Alice of Wonderland"
}
```
</CodeBlockConfig>
The following are some examples of using these values in filters:
- `"operator" in "/userinfo/roles"` matches users (like Alice) that have
`"operator"` in the roles returned by UserInfo.
- `"/token/custom/department" == "infosec" or "/token/custom/department" == "ops"` matches users (like Alice) that are either in the `ops` or `infosec` departments.
## LDAP managed groups
Membership is determined by matching the LDAP group names against an LDAP account's associated groups.
Every authentication updates the group membership comparison.
To enable managed groups, set the LDAP auth method `enable_groups` attribute to `true`.
After you enable groups on the auth method, the managed group membership is defined as a list with the `group-names` attribute on the managed group itself.
### LDAP auth method search filter attributes
When you define the auth method, you can set a number of group and user attributes to resolve group membership according to the structure of your directory schema.
You can set an optional `group_dn` to define the base distinguished name (DN) to perform a group search under. A common example is:
`ou=Groups,dc=example,dc=com`
Because the directory schema can vary, you may specify a `group_filter` that constructs a group membership query from a template. The following default template is compatible with several common directory schemas:
You may also set a `group_attr` value that enumerates group membership based on the objects returned from the `group_filter`. Common examples include:
- `group_filter` queries returning group objects, use: `cn`. This is the default.
- `group_filter` queries returning user objects, use: `memberOf`.
### LDAP examples
Directory schemas can vary according to your implementation.
We provide some examples in this section using the schema declared for the [Online LDAP Test Server](https://www.forumsys.com/2022/05/10/online-ldap-test-server/) provided by ForumSystems.
Refer to your directory schema for the specific syntax.
LDAP server information (read-only access):
Server: `ldap.forumsys.com `
Port: `389`
Bind DN: `cn=read-only-admin,dc=example,dc=com`
Bind password: `password`
All user passwords are `password`. You may also bind to individual Users (uid) or the two Groups (ou) that include:
