Skip to content

Add principalClaim attribute to OIDC AuthClass in ADR on OIDC #498

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Dec 4, 2023
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 18 additions & 1 deletion modules/contributor/pages/adr/ADR032-oidc-support.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,7 @@ http-server.authentication.oauth2.client-id: trino
http-server.authentication.oauth2.client-secret: ${ENV:TRINO_CLIENT_SECRET}
http-server.authentication.oauth2.issuer: https://${ENV:KEYCLOAK_ADDRESS}/realms/master
http-server.authentication.oauth2.scopes: openid
http-server.authentication.oauth2.principal-field: preferred_username
```

==== Druid
Expand Down Expand Up @@ -89,7 +90,7 @@ Does not support reading an OIDC discovery URL but requires:
We could opt to implement proper OIDC support using fab-oidc. This however needs maintenance work from us.

```
{
{
'name': 'keycloak',
'icon': 'fa-key',
'token_key': 'access_token',
Expand Down Expand Up @@ -163,6 +164,22 @@ spec:
# remove some from this list.
scopes: [ openid, email, profile ]

# If a product extracts some sort of "effective user" that is represented by a
# string internally, this config determines with claim is used to extract that
# string. It is desirable to use `sub` in here (or some other stable identifier),
# but in many cases you might need to use `preferred_username` (e.g. in case of Keycloak)
# or a different claim instead.
#
# Please note that some products hard-coded the claim in their implementation,
# so some product operators might error out if the product hardcodes a different
# claim than configured here.
#
# We don't provide any default value, as there is no correct way of doing it
# that works in all setups. Most demos will probably use `preferred_username`,
# although `sub` being more desirable, but technically impossible with the current
# behavior of the products.
principalClaim: preferred_username

# Optional provider hint. If unspecified, the product will not
# enable any known quirks and will assume OIDC works as it is
# intended to work.
Expand Down