mirror of https://github.com/hashicorp/boundary
Robin Beck
2 years ago
parent
be7d72d690
commit
f7daa1fb55
@ -0,0 +1,167 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Filtering - managed groups
|
||||
description: |-
|
||||
How to configure filters for managed groups within the OIDC or LDAP auth methods.
|
||||
---
|
||||
|
||||
[filter syntax]: /boundary/docs/concepts/filtering
|
||||
|
||||
# Filter managed groups
|
||||
|
||||
This page describes how to use filters with OIDC or LDAP managed groups. It assumes that the reader is familiar with the general [filter syntax][] as well as with [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) or [LDAP](https://ldap.com/ldap-specifications/).
|
||||
|
||||
|
||||
## OIDC filters
|
||||
|
||||
Currently, two blocks of data are available for these filters for OIDC:
|
||||
|
||||
- `/token/<claims>` contains claims from the JWT returned by the OIDC Identity
|
||||
Provider (IdP). For example, `/token/sub` is the `"sub"` claim from the token.
|
||||
|
||||
- `/userinfo/<claims>` contains claims from the
|
||||
[UserInfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)
|
||||
endpoint.
|
||||
|
||||
### OIDC examples
|
||||
|
||||
As the content of these claims is specific to the given IdP (other than those
|
||||
claims mandated by the OIDC specification), no specific syntax can be conveyed,
|
||||
but some examples are given below using contrived sets of claims.
|
||||
|
||||
Given the example claims below:
|
||||
|
||||
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"` would match users (like Alice) that have
|
||||
`"operator"` in the roles returned in the UserInfo reply.
|
||||
|
||||
- `"/token/custom/department" == "infosec" or "/token/custom/department" == "ops"` would match 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, and every authentication updates the group membership comparison.
|
||||
|
||||
To enable managed groups, the LDAP auth method `enable_groups` attribute should be set to `true`.
|
||||
|
||||
After enabling 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 filter attributes
|
||||
|
||||
When defining the auth method, a number of group and user attributes can be set to resolve group membership according to the structure of your directory schema.
|
||||
|
||||
An optional `group_dn` can be set to define the base DN to perform a group search under. A common example is:
|
||||
|
||||
`ou=Groups,dc=example,dc=com`
|
||||
|
||||
Because the directory schema can vary, a `group_filter` may be specified that constructs a group membership query from a template. The following default template is compatible with several common directory schemas:
|
||||
|
||||
`(|(memberUid={{.Username}})(member={{.UserDN}})(uniqueMember={{.UserDN}}))`
|
||||
|
||||
A `group_attr` may also be set 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
|
||||
|
||||
Because directory schemas can vary according to implementation, no specific syntax can be conveyed, but some examples are given below using the schema declared for the [Online LDAP Test Server](https://www.forumsys.com/2022/05/10/online-ldap-test-server/) provided by ForumSystems.
|
||||
|
||||
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:
|
||||
|
||||
Mathematicians: `ou=mathematicians,dc=example,dc=com`
|
||||
- riemann
|
||||
- gauss
|
||||
- euler
|
||||
- euclid
|
||||
|
||||
Scientists: `ou=scientists,dc=example,dc=com`
|
||||
- einstein
|
||||
- newton
|
||||
- galieleo
|
||||
- tesla
|
||||
|
||||
Example LDAP auth method attributes:
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```text
|
||||
Attributes:
|
||||
bind_dn: cn=read-only-admin,dc=example,dc=com
|
||||
bind_password_hmac: IC29KNPDTPC57nc2aT9UFthOh4Kh1i3660_euBsgL7Y
|
||||
enable_groups: true
|
||||
group_dn: dc=example,dc=com
|
||||
state: active-public
|
||||
urls: [ldap://ldap.forumsys.com]
|
||||
user_attr: uid
|
||||
user_dn: dc=example,dc=com
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
In this example, the following attributes are set on the LDAP auth method:
|
||||
|
||||
- `urls:` `"ldap://ldap.forumsys.com"`
|
||||
- `bind-dn`:` "cn=read-only-admin,dc=example,dc=com"`
|
||||
- `bind-password`:` file://bind-pass.txt` (passed directly if using Terraform)
|
||||
- `user-dn`:` "dc=example,dc=com"`
|
||||
- `user-attr`:` "uid"`
|
||||
- `group-dn`:` "dc=example,dc=com"`
|
||||
|
||||
Example managed group attributes:
|
||||
|
||||
<CodeBlockConfig hideClipboard>
|
||||
|
||||
```text
|
||||
Attributes:
|
||||
group_names: [Mathematicians]
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
In this example, the following attribute is set on the managed group:
|
||||
|
||||
- `group-names`: `"Mathematicians"`
|
||||
@ -1,69 +0,0 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Filtering - OIDC managed groups
|
||||
description: |-
|
||||
How to configure filters for managed groups within the OIDC auth method.
|
||||
---
|
||||
|
||||
[filter syntax]: /boundary/docs/concepts/filtering
|
||||
|
||||
# Filter OIDC managed groups
|
||||
|
||||
This page describes how to use filters with OIDC managed groups. It assumes that
|
||||
the reader is familiar with the general [filter syntax][] as well as with
|
||||
[OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html).
|
||||
|
||||
~> **Note:** This feature was introduced in Boundary 0.3.0.
|
||||
|
||||
Currently, two blocks of data are available for these filters:
|
||||
|
||||
- `/token/<claims>` contains claims from the JWT returned by the OIDC Identity
|
||||
Provider (IdP). For example, `/token/sub` is the `"sub"` claim from the token.
|
||||
|
||||
- `/userinfo/<claims>` contains claims from the
|
||||
[UserInfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)
|
||||
endpoint.
|
||||
|
||||
## Examples
|
||||
|
||||
As the content of these claims is specific to the given IdP (other than those
|
||||
claims mandated by the OIDC specification), no specific syntax can be conveyed,
|
||||
but some examples are given below using contrived sets of claims.
|
||||
|
||||
Given the example claims below:
|
||||
|
||||
Example JWT claims:
|
||||
|
||||
```json
|
||||
{
|
||||
"iss": "https://server.example.com",
|
||||
"sub": "24400320",
|
||||
"aud": "s6BhdRkqt3",
|
||||
"nonce": "n-0S6_WzA2Mj",
|
||||
"exp": 1311281970,
|
||||
"iat": 1311280970,
|
||||
"auth_time": 1311280969,
|
||||
"custom": {
|
||||
"department": "infosec"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Example UserInfo claims:
|
||||
|
||||
```json
|
||||
{
|
||||
"roles": ["user", "operator"],
|
||||
"sub": "alice@example.com",
|
||||
"email": "rabbithole@example.com",
|
||||
"name": "Alice of Wonderland"
|
||||
}
|
||||
```
|
||||
|
||||
Following are some examples of using these values in filters:
|
||||
|
||||
- `"operator" in "/userinfo/roles"` would match users (like Alice) that have
|
||||
`"operator"` in the roles returned in the UserInfo reply.
|
||||
|
||||
- `"/token/custom/department" == "infosec" or "/token/custom/department" == "ops"` would match users (like Alice) that are either in the `ops` or `infosec`
|
||||
departments.
|
||||
Loading…
Reference in new issue