-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Implements the jwt-bearer grant type as described in RFC 7523 for uti… #24512
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,21 @@ | ||
| [[cross_domain_trust]] | ||
| === Configuring Cross-Domain Trusts | ||
|
|
||
| Cross-domain trusts can be defined at the realm level to specify trusted security domains external to Keycloak. This set of trusted | ||
| domains is used by other features, such as the <<_assertion_grant,JWTs as Authorization Grants>> feature which allows external entities | ||
| to request access tokens for users. | ||
|
|
||
| To configure a trusted domain: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd imagine there would be a need to be able to lock down things further to have checks on claims within the assertions. For example if a different Keycloak server is the trusted domain, then since Keycloak uses JWTs for refresh, ID, and access tokens, there would need to be some mechanism to for example only permit ID tokens. For other providers there could be other claims that would need to be checked. |
||
|
|
||
| . Go to `Realm settings` | ||
| . Select the `Cross-Domain Trust` tab | ||
| . Create a trusted domain entry | ||
| . Save the changes | ||
|
|
||
| Each cross-domain trust configuration contains 3 elements: | ||
|
|
||
| * Issuer: The URI identifying this trusted domain. This value will be used to verify the issuer on assertions signed by this trusted domain. | ||
| * Audience: The URI identifying the audience of assertions submitted by this trusted domain. This value will be used to verify the audience on assertions signed by this trusted domain. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if there are multiple audiences, and different client use different audiences? As an example let's imagine we're setting up a cross-domain trust with Google as the assertion provider. In a realm there are two clients (client-a and client-b), where each client has their own client configured with Google. |
||
| * Certificate: The base64 encoded X509 signing certificate of the trusted domain. This will be used to verify assertions signed by this trusted domain. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would be natural to support jwks urls here
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does it have to be ceritificate? It would be useful in the case when the issuer of assertion is Okta, because Okta looks provide only public key, not certificate for signature verification of the assertion. |
||
|
|
||
| image:images/cross-domain-trust-table.png[alt="Cross-Domain Trust Configuration Table"] | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -101,6 +101,23 @@ This is used by clients running on internet-connected devices that have limited | |
| . The application provides the user with the user code and the verification URI. The user accesses a verification URI to be authenticated by using another browser. You could define a short verification_uri that will be redirected to {project_name} verification URI (/realms/realm_name/device)outside {project_name} - fe in a proxy. | ||
| . The application repeatedly polls {project_name} to find out if the user completed the user authorization. If user authentication is complete, the application exchanges the device code for an _identity_, _access_ and _refresh_ token. | ||
|
|
||
| [[_assertion_grant]] | ||
| ===== JWTs as Authorization Grants | ||
|
|
||
| The JWTs as authorization grants flow described in https://www.rfc-editor.org/rfc/rfc7523#section-2.1[RFC 7523 Section 2.1] enables trusted entities to authenticate users by submitting a signed JWT to the OIDC token endpoint. | ||
|
|
||
| The protocol works as follows: | ||
|
|
||
| . A trusted entity generates a JWT, specifying the username of the user in the _sub_ claim of the JWT | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The username from the assertion does not necessarily map directly to a username in Keycloak. |
||
| . The trusted entity signs the JWT with the private key assocated with a pre-registered certificate (see the <<_assertion_grant_configuration,Assertion Grant Trusted Issuer Configuration>> chapter for configuring trusted certificates) | ||
| . The trusted entity submits the JWT to the oidc _token_ endpoint with _grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer_ | ||
| . Keycloak validates the submitted assertion against cross-domain trusts in the client configuration | ||
| . If the assertion is valid, Keycloak creates an authentication session for the requested user and returns the generated OIDC tokens | ||
|
||
|
|
||
| To perform assertion grant requests, the client submitting the assertion grant request must be authorized to impersonate users. | ||
|
|
||
| For details on fine grain permissions and the _impersonate_ role, see the <<full-list-of-permissions,Fine grain admin permissions>> chapter. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I assume token exchange (and fine grained admin perissions) allows limiting what users can be impersonated? For example a specific group of users. |
||
|
|
||
| [[_client_initiated_backchannel_authentication_grant]] | ||
| ===== Client initiated backchannel authentication grant | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,44 @@ | ||
| import { useTranslation } from "react-i18next"; | ||
| import { ActionGroup, Button } from "@patternfly/react-core"; | ||
|
|
||
| import { FormAccess } from "../../components/form/FormAccess"; | ||
| import { convertAttributeNameToForm } from "../../util"; | ||
| import type { AdvancedProps } from "../AdvancedTab"; | ||
| import { CrossDomainSelect } from "../../components/cross-domain/crossDomainSelect"; | ||
|
|
||
| export const AssertionGrantConfigPanel = ({ | ||
| save, | ||
| client: { access, protocol }, | ||
| }: AdvancedProps) => { | ||
| const { t } = useTranslation(); | ||
|
|
||
| return ( | ||
| <FormAccess | ||
| role="manage-clients" | ||
| fineGrainedAccess={access?.configure} | ||
| isHorizontal | ||
| > | ||
| {protocol === "openid-connect" && ( | ||
| <> | ||
| <CrossDomainSelect | ||
| name={convertAttributeNameToForm( | ||
| "attributes.oidc.grants.assertion.config", | ||
| )} | ||
| label={t("oidcClientJWTBearerCrossDomainTitle")} | ||
| helpText={t("oidcClientJWTBearerCrossDomainHelp")} | ||
| onChange={(d) => JSON.stringify(d.map((c) => c.issuer))} | ||
| onLoad={(trustedDomains, data) => { | ||
| const loaded = JSON.parse(data || "[]"); | ||
| return trustedDomains.filter((c) => loaded.includes(c.issuer)); | ||
| }} | ||
| /> | ||
| <ActionGroup> | ||
| <Button variant="secondary" onClick={() => save()}> | ||
| {t("save")} | ||
| </Button> | ||
| </ActionGroup> | ||
| </> | ||
| )} | ||
| </FormAccess> | ||
| ); | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about identity brokers, would it make sense to somehow link this concept of trusted domains with identity broker providers?