You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/en/operations/external-authenticators/tokens.md
+24-18Lines changed: 24 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,25 +13,21 @@ OAuth 2.0 access tokens can be used to authenticate ClickHouse users. This works
13
13
14
14
Though this authentication method is different from JWT authentication, it works under the same authentication method to maintain better compatibility.
15
15
16
-
For both of these approaches a definition of `access_token_processors` is mandatory.
16
+
For both of these approaches a definition of `token_processors` is mandatory.
17
17
18
18
## Access Token Processors
19
19
20
-
To define an access token processor, add `access_token_processors` section to `config.xml`. Example:
20
+
To define an access token processor, add `token_processors` section to `config.xml`. Example:
@@ -42,11 +38,12 @@ Different providers have different sets of parameters.
42
38
**Parameters**
43
39
44
40
-`provider` -- name of identity provider. Mandatory, case-insensitive. Supported options: "Google", "Azure", "OpenID".
41
+
-`username_claim` -- name of claim (field) that will be treated as ClickHouse user name. Optional, default: "sub".
45
42
-`cache_lifetime` -- maximum lifetime of cached token (in seconds). Optional, default: 3600.
46
43
-`email_filter` -- Regex for validation of user emails. Optional parameter, only for Google IdP.
47
44
-`client_id` -- Azure AD (Entra ID) client ID. Optional parameter, used only for Azure IdP.
48
45
-`tenant_id` -- Azure AD (Entra ID) tenant ID. Optional parameter, used only for Azure IdP.
49
-
-`groups_claim_name` -- Name of claim (field) that contains list of groups user belongs to. This claim will be looked up in the token itself (in case token is a valid JWT, e.g. in Keycloak) or in response from `/userinfo`. Optional parameter.
46
+
-`groups_claim` -- Name of claim (field) that contains list of groups user belongs to. This claim will be looked up in the token itself (in case token is a valid JWT, e.g. in Keycloak) or in response from `/userinfo`. Optional parameter.
50
47
-`configuration_endpoint` -- URI of `.well-known/openid-configuration`. Optional parameter, useful only for OIDC-compliant providers (e.g. Keycloak).
51
48
-`userinfo_endpoint` -- URI of userinfo endpoint. Optional parameter.
52
49
-`token_introspection_endpoint` -- URI of token introspection endpoint. Optional parameter.
@@ -67,17 +64,20 @@ Locally defined users can be authenticated with an access token. To allow this,
67
64
68
65
```xml
69
66
<clickhouse>
70
-
<!- ... -->
71
67
<users>
72
-
<!- ... -->
73
68
<my_user>
74
-
<!- ... -->
69
+
<jwt>
70
+
<allowed_processors>
71
+
<azuure />
72
+
</allowed_processors>
75
73
</jwt>
76
74
</my_user>
77
75
</users>
78
76
</clickhouse>
79
77
```
80
78
79
+
Inside `jwt` one or more specific access token processors names can be specified -- only those processors will be tried when authenticating. If no processors are specified, _all_ processors will be tried.
80
+
81
81
At each login attempt, ClickHouse will attempt to validate token and get user info against every defined access token provider.
82
82
83
83
When SQL-driven [Access Control and Account Management](/docs/en/guides/sre/user-management/index.md#access-control) is enabled, users that are authenticated with tokens can also be created using the [CREATE USER](/docs/en/sql-reference/statements/create/user.md#create-user-statement) statement.
@@ -94,7 +94,7 @@ If there is no suitable user pre-defined in ClickHouse, authentication is still
94
94
To allow this, add `token` section to the `users_directories` section of the `config.xml` file.
95
95
96
96
At each login attempt, ClickHouse tries to find the user definition locally and authenticate it as usual.
97
-
If the user is not defined, ClickHouse will treat user as externally defined, and will try to validate the token and get user information from the specified processor.
97
+
If the user is not defined, ClickHouse will treat the user as externally defined and will try to validate the token and get user information from the specified processor.
98
98
If validated successfully, the user will be considered existing and authenticated. The user will be assigned roles from the list specified in the `roles` section.
99
99
All this implies that the SQL-driven [Access Control and Account Management](/docs/en/guides/sre/user-management/index.md#access-control) is enabled and roles are created using the [CREATE ROLE](/docs/en/sql-reference/statements/create/role.md#create-role-statement) statement.
100
100
@@ -105,15 +105,21 @@ All this implies that the SQL-driven [Access Control and Account Management](/do
105
105
<user_directories>
106
106
<token>
107
107
<processor>processor_name</processor>
108
-
<roles>
108
+
<common_roles>
109
109
<token_test_role_1 />
110
-
</roles>
110
+
</common_roles>
111
+
<roles_filter></roles_filter>
111
112
</token>
112
113
</user_directories>
113
114
</clickhouse>
114
115
```
115
116
117
+
:::note
118
+
For now, no more than one `token` section can be defined inside `user_directories`. This _may_ change in future.
119
+
:::
120
+
116
121
**Parameters**
117
122
118
-
-`processor` — Name of one of processors defined in `access_token_processors` config section described above. This parameter is mandatory and cannot be empty.
119
-
-`roles` — Section with a list of locally defined roles that will be assigned to each user retrieved from the IdP.
123
+
-`processor` — Name of one of processors defined in `token_processors` config section described above. This parameter is mandatory and cannot be empty.
124
+
-`common_roles` — Section with a list of locally defined roles that will be assigned to each user retrieved from the IdP. Optional.
125
+
-`roles_filter` — Regex string for groups filtering. Only groups matching this regex will be mapped to roles. Optional.
0 commit comments