This PR is for KEYCLOAK-12137 OpenID Connect Client Initiated Backchannel Authentication (CIBA), also is the part of the project FAPI-CIBA(poll mode) of FAPI-SIG activity.

Generally speaking, the aim of this PR is to support CIBA Flow defined in the design document.

However, this PR does not support Financial-grade API: Client Initiated Backchannel Authentication Profile (FAPI-CIBA) feature. As mentioned in the 8th meeting of FAPI-SIG, I will send PRs for FAPI-CIBA features consecutively after this PR supporting pure CIBA being merged.

This PR is still huge so that I will add detailed comments on the commits to help the reviewer grasp them.

This PR has been written with the contribution by @andriimurashkin as FAPI-SIG activities..

Describe the bug

Following (https://github.com/keycloak/keycloak/issues/10817), I've updated keycloak the newest version (18), and I'm still running in to some issues.

As described, the current proxy setting is edge

First issues is that when the server is first spawn up, we get a redirect_uri error:

LOGS:

DEBUG [io.quarkus.vertx.http.runtime.ForwardedParser] (executor-thread-11) Recalculated absoluteURI to http://something.com/auth/realms/master/protocol/openid-connect/auth?client_id=security-admin-console&redirect_uri=https%3A%2F%2Fsomething.com%2Fauth%2Fadmin%2Fmaster%2Fconsole%2F&state=fbd3f10a-d929-4af8-a4ce-e3ef06c1b89e&response_mode=fragment&response_type=code&scope=openid&nonce=ea937eae-bcc6-4bf3-aae3-0a4b3742c9d7&code_challenge=pNq3qur9_XOZfrTirOaHRMxCx8pdGL-yeFjAKbLLiHA&code_challenge_method=S256

DEBUG [org.keycloak.protocol.oidc.utils.RedirectUtils] (executor-thread-11) replacing relative valid redirect with: http://something.com/auth/admin/master/console/*

WARN [org.keycloak.events] (executor-thread-11) type=LOGIN_ERROR, realmId=a1634d31-f503-4b6b-9ce9-522e84855fc7, clientId=security-admin-console, userId=null, ipAddress=40.41.43.44, error=invalid_redirect_uri, redirect_uri=https://something.com/auth/admin/master/console/

Here we can see that calls are reaching the keycloak server as http, so I'm guessing that nginx ingress is forwarding the headers correctly, however its expected that the server knows that its being redirected from an https origin and should allow for access as such. This does not happen as we get the aforementioned redirect_uri error.

To fix this, we need to add the absoluteURI to the redirect_uris of the security-admin-console client using kcadm:

./kcadm.sh update clients/ -s 'redirectUris=["https://something.com/auth/*"]' --no-config --server http://localhost:8080/auth --realm master --user admin --password admin

We can now enter the password and the user to get access to the admin console, but some requests are generated with the wrong scheme:

If we copy the request as cURL we get the following:

curl 'http://something.com/auth/admin/realms' -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0' -H 'Accept: application/json, text/plain, /' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate' -H 'Authorization: Bearer <TOKEN>' -H 'Origin: https://something.com'

As we can see the address is generated with HTTP, at this point the browser identifies this as a possible risk and flags the requests as MIXED BLOCK. I'm not able to get any logs from this as the browser doesn't even try to reach the server. However if we take this and change to HTTPS and run the cURL command its is successful.

There are however some requests that are generated correctly:

So my guess is that something in the client-sided application is generating the urls incorrectly.

Is this a known bug or is it some miss configuration on my side?

My current setup is as follows: KEYCLOAK 18 (quarkus): KC_PROXY=EDGE KC_HOSTNAME=something.com KC_PORT = 8080 KC_HTTP_RELATIVE_PATH=/auth

Cloud Provicer is AWS Running on Kubernentes (EKS) INGRESS-CONTROLLER = nginx Ingress variables: host: something.com path: / port: 8080

Version

18

Expected behavior

Not getting redirect_url error and being able to access the admin console.

Actual behavior

Getting redirect_url on a fresh instance and not being able to access the admin console.

How to Reproduce?

Spawn a new keycloak instance in kubernetes with KC_PROXY=edge and with an nginx ingress. Then just access the browser on the defined url.

Anything else?

https://github.com/keycloak/keycloak/issues/10817 https://github.com/keycloak/keycloak/issues/11667 https://keycloak.discourse.group/t/mixed-block-error-on-api-request-on-the-admin-console/15178

Description

Need to return the ability to import realm at the start of the application to simplify its initial configuration

Discussion

Export/Import of realm data (JSON) #10229

Motivation

Now we have to wait until Keycloak starts and do the import using one of the ways

1. Using kcadm.sh

/opt/keycloak/bin/kcadm.sh config credentials --server http://localhost:8080/auth --realm master --user ${KEYCLOAK_ADMIN} --password ${KEYCLOAK_ADMIN_PASSWORD}
/opt/keycloak/bin/kcadm.sh create realms -f /tmp/realm.json'

2. Using new kc.sh import which requires restarting Keycloak

/opt/keycloak/bin/kc.sh import --file /tmp/realm.json

Please simplify our life and return the opportunity to make import realm from a file using a startup variable because I try to create a guide on how to simple run Keycloak in Docker Compose v2 and this problem prevents the automation of the process

Details

In the Keycloak 16.1.1 and previous versions

  keycloak:
    image: "quay.io/keycloak/keycloak:16.1.1"
    environment:
      - KEYCLOAK_IMPORT=/tmp/realm.json
    volumes:
      - ./realm.json:/tmp/realm.json:ro

In the Keycloak 17.0.0, it doesn't work even though I tried different variables and there are no errors in the log either

  keycloak:
    image: "quay.io/keycloak/keycloak:17.0.0"
    environment:
      - KEYCLOAK_IMPORT=/tmp/realm.json
      - KC_IMPORT=/tmp/realm.json
    volumes:
      - ./realm.json:/tmp/realm.json:ro

Duplicate of #9261

This PR is the continuity of https://github.com/keycloak/keycloak/pull/6267 which was not merged at the time. I think it's better for whomever reviews this to take a look at the closed PR to have more context. Due to lack of time to address some review comments at the time, the PR was discarded. Hopefully, this time the PR fullfills the requirements. Here are the points that were addressed in the follow-up commit:

:heavy_check_mark: Convert to AIA :heavy_check_mark: Remove realm option as it's not needed since delete account role has to be associated with user before the user can delete the account :heavy_check_mark: Rename role to delete-account :heavy_check_mark: delete-account should not be a realm role, seems PR supports it as both realm role and client role :heavy_check_mark: Missing migration code adding role to existing realms in the DB

It would be ideal if the original PR reviewer, @stianst also takes a look.

Please do not merge, docs & tests are a work in progress. User authentication via X.509 client certificates. The implementation includes support for browser and direct grant flows. See services\src\main\java\org\keycloak\authentication\authenticators\x509\README.md for a brief summary of proposed changes/additions.

For OCSP certificate revocation checking to work properly, WFCORE-1705 must be resolved.

This changes the themes pom to work with more than one package.json file. The only other one at the moment is for the new account console / account2.

I was not able to use one global node_modules directory, and make it work with all the requirements, like being able to run the account2 build scripts, and working with Windows, etc. So, there are two directories, with the possiblity of multiple copies of a module.

However, I should have saved some megabytes elsewhere, by changing how the filters run. They used to be done when updating the modules, but now they are applied at build time, so there's no second copy of the filtered files in git. This also has the advantage of allowing the filters to affect the modules globally, and avoids copying them for each package.json.

The documentation has been updated to reflect the new changes.

Since we're building directly out of the source directories, it is possible in a local dev environment for unintended files (e.g. old compiled .js files), placed within src/main/resources/, to be included in the themes jar. This shouldn't be a problem for actual builds though, which use a fresh clone.

Other small changes include refactoring the npm setup stuff to a global definition, and the introduction of some properties to avoid duplicating path definitions everywhere.

This commit does not include the churn that would result from running the update command: mvn clean -Pnpm-update package I think it best to keep that in its own commit.

Notes to the reviewers:

• The first commit is actually a workaround for KEYCLOAK-4342 (see #4056). Have a look; I think it could be a pragmatic first improvement without needing to implement a reliable way of establishing the context path. If it's good enough I'll turn it into a separate PR.
• It feels like the cookie based login redirect (2nd commit) should be in a different place, but this is what I came up with to get it to work for our application. Maybe someone who knows a bit more about the internal state keeping of the adapters can suggest a nicer way of doing this.
• I had to change the position of the KeycloakAuthenticationProcessingFilter in the filter chain (3rd commit), because otherwise the logout would be initiated before the credentials were retrieved from the cookie. I'm unsure what the implications are for the SSO logout in relation to Keycloak sessions and HTTP sessions (if enabled), but it seems to do what I want in local testing.
• I have not spent any effort on writing tests yet, because I'm unsure where/how to add tests (is there an existing integration test I can amend?). Any pointers would be appreciated.
• I'm unsure if these changes affect the behaviour of the Spring Boot adapter. Looking at the code, it seems that adapter operates independently from the Spring Security one, but the pom.xml does declare keycloak-spring-security-adapter as a dependency, so maybe there's some class path magic going on that I did not spot.

I proposed this workaround in #4283 to be able to add support for token storage in cookies in the Spring adapter. It touches the CookieTokenStore though, which is shared by a number of other adapters.

Key idea was: change the way the cookie path is determined in a backward compatible way, but with the option to override it. The current behaviour assumes that the application is never running on the root path of the server, so we'll need to maintain that as the default. Therefore, I introduced the adapterStateCookiePath property in KeycloakDeployment, which allows you to configure where the cookie will be stored. If it's a relative path, then it is assumed that the application is running in a context root, and is interpreted relative to that context root. If it's an absolute path, then that path is used to store the cookies. This behaviour is documented by CookieTokenStoreTest.

Fix #11875

This PR adds an UPDATE_EMAIL action (enabled by default) that can be used as an AIA or a required action. The action is associated with a single email input form. If the realm has email verification disabled, this action will allow to update the email without verification. If the realm has email verification enabled, the action will send an email update action token to the new email address without changing the account email. Only the action token triggering will complete the email update.

In the account application personal info (Keycloak V2), this PR turns the email input field into a permanent readonly field. If the UPDATE_EMAIL action is enabled, an "Update Email" link will allow to trigger UPDATE_EMAIL action as an AIA. If the UPDATE_EMAIL action is disabled, there will be no link and therefore no way to update the email from the personal info page.

This PR conditionally removes the email field from login-update-profile.ftl form:

• if the form is opened in a brokered identity context, the email field is kept
• otherwise, the email field is removed

• Check out the Jira ticket for the reason for this PR, too
• This upgrades to select2 4.0.10
• Due to that, angular-ui-select2 was not working any more. As this project is obsolete, I used a newer library (also checked vuln. DBs) called ui-select (v0.19.8)
• I also found a problem with redundantly checked in JS dependencies and cleaned this up by deleting themes/src/main/node_modules/
  • Once npm install is run, it puts all under themes/src/main/node_modules/
  • From there, a special npm build of Maven is used to copy it to the target directory to themes/src/main/resources/theme/keycloak/common/resources/node_modules/
  • The latter folder is the one used for all distribution builds, the former one is just temporary and can be removed therefore
• Easier review is possible by splitting your review into all files that contain "node_modules" in their name and all others

Adds support for OAuth on Cordova using the native Browser and Universal Links. This relies on two cordova-plugins:

• browsertab: https://github.com/google/cordova-plugin-browsertab
• universal-links: https://github.com/nordnet/cordova-universal-links-plugin

See http://lists.jboss.org/pipermail/keycloak-dev/2018-May/010864.html for discussions about this feature.

There's an example app here: https://github.com/gtudan/ionic2-keycloak

Before reporting an issue

• [X] I have searched existing issues
• [X] I have reproduced the issue with the latest release

Area

account/api

Describe the bug

Verbose doesn't work as well

Version

Latest

Expected behavior

Start

Actual behavior

Stop

How to Reproduce?

Try to start

Anything else?

:(

Before reporting an issue

• [X] I have searched existing issues
• [X] I have reproduced the issue with the latest release

Area

core

Describe the bug

It doesn't work :(

Version

Latest

Expected behavior

Start

Actual behavior

Stop

How to Reproduce?

Try to start

Anything else?

no

Before reporting an issue

• [X] I have searched existing issues
• [X] I have reproduced the issue with the latest release

Area

admin/ui

Describe the bug

In the latest release of keycloak, using the "Import Client" feature fails when the first line of an XML file imported is blank.

This produces an error, saying:

Version

20.0.2

Expected behavior

Client configurations should import successfully. If the extension of an imported client is XML, this should be enough to deduce the format of the file imported, and the file should be parsed as an XML file instead of JSON.

Actual behavior

"Import Client" fails, presumably because Keycloak is trying to interpret an XML file as JSON.

How to Reproduce?

You can download a config file from SamlTest.id from https://samltest.id/saml/sp . This file has a blank first line. Rename the file to .xml, attempt to import, and the import will fail because of a blank first line. When the file is edited and the first line is no longer blank, the file is parsed correctly and no errors are raised.

Anything else?

No response

Before reporting an issue

• [X] I have searched existing issues
• [X] I have reproduced the issue with the latest release

Area

authentication

Describe the bug

The "Used by" column in the Authentication page used to / should display the name of the default flow it is bound to like "Registration flow" or "Browser flow".

In 20.0.2, instead of displaying the flow it's bound to, it just displays the flow's own name.

Version

20.0.2

Expected behavior

If I create a new flow named "broken" and bind it to "Direct grant flow", I would expect it to be listed with "Used by" stating "Direct grant"

Actual behavior

When creating a fresh empty flow named "broken" and binding it to "Direct grant flow", the following is displayed in the Authentication page -> Flows tab listing:

How to Reproduce?

1. Go to Authentication page -> Flows tab.
2. Execute "Create flow" with distinct name like "goof". Flow type does not matter.
3. In the "goof" flow details page, click the top right "Action" select dropdown and choose "Bind flow"
4. In the "Bind flow" dialog that pops up, choose "Direct grant flow" and click "Save".
5. Go back to the Authentication page -> Flows Tab and observe the listing for "goof"

Anything else?

No response

Before reporting an issue

• [X] I have searched existing issues
• [X] I have reproduced the issue with the latest release

Area

admin/api

Describe the bug

List org.keycloak.admin.client.resource.ResourcesResource.find() does not accept "matchingUri", "exactName" and "deep" parameters. AND returned ResourceRepresentation object does not contain resource ID value.

{
    "name": "API...",
    "owner": {
        "id": "xxx",
        "name": "xxx"
    },
    "ownerManagedAccess": false,
    "attributes": {},
    "_id": "90735035-2525-4d11-b692-770b9c1e7b93",
    "uris": [
        "/api/rest/...,
    ],
    "scopes": [
        {
            "id": "1da879e7-b77f-4a6b-ba56-30b7128a492d",
            "name": "POST"
        }
    ]
}

Version

20.0.2

Expected behavior

Java Rest API should match parameters and return values of REST api.

Actual behavior

Return value miss resource ID value and API does not accept "matchingUri", "exactName" and "deep" parameters.

How to Reproduce?

Check java api definition and return value.

Anything else?

No response

Before reporting an issue

• [X] I have searched existing issues
• [X] I have reproduced the issue with the latest release

Area

authorization-services

Describe the bug

When I make following request with Javascript adapter

keycloak.login({
    acr: {
        value: "gold",
        transactionId: "1234"
    }
})

then:

• keycloak logs UnrecognizedPropertyException error
• and token is generated but with different acr level that was requested due to previous error

Version

19.0.0

Expected behavior

1. Keycloak should return requested "acr" claim in the token
2. Additionally keycloak should allow developer to return additional claims in the token. This is possible by implementing custom token mapper.

Actual behavior

1. Following error is logged in the console

2022-12-29 19:07:40,710 WARN  [org.keycloak.protocol.oidc.utils.AcrUtils] (vert.x-worker-thread-4) Invalid claims parameter: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "transactionId" (class org.keycloak.representations.ClaimsRepresentation$ClaimValue), not marked as ignorable (3 known properties: "value", "values", "essential"])
 at [Source: (String)"{"id_token":{"acr":{"value":"gold","transactionId":"1234"}}}"; line: 1, column: 53] (through reference chain: org.keycloak.representations.ClaimsRepresentation["id_token"]->java.util.LinkedHashMap["acr"]->org.keycloak.representations.ClaimsRepresentation$ClaimValue["transactionId"])
	at com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException.from(UnrecognizedPropertyException.java:61)
	...
	at org.keycloak.util.JsonSerialization.readValue(JsonSerialization.java:75)
	at org.keycloak.protocol.oidc.utils.AcrUtils.getAcrValues(AcrUtils.java:62)
	at org.keycloak.protocol.oidc.mappers.AcrProtocolMapper.getAcr(AcrProtocolMapper.java:113)
	at org.keycloak.protocol.oidc.mappers.AcrProtocolMapper.setClaim(AcrProtocolMapper.java:86)

2. keycloak returns different acr than requested

How to Reproduce?

Configure Step-Up flow according to official docs and issue request with additional claims in acr

Anything else?

This can be fixed simply by adding @JsonIgnoreProperties(ignoreUnknown = true) to ClaimsRepresentation. I can spare few minutes to prepare a Pull Request with such a fix.

I have small additional related questions.

1. If my understanding is correct then Request Objects or JAR (JWT secured authorization request) would be bit better for my use case but I can't see any official documentation regarding that. I have seen some PRs/discussions here on github, but I am not sure if this officially supported. To me it also looks like it's kind of supported by the keycloak server, but I don't see such support in the javascript adapter. Any comments on that? a. Is Request Object/JAR supported by keycloak server? b. Is Request Object/JAR supported javascript adapter?
2. Also it seems that claims parameter is supported by certain protocol mappers but seem to be undocummented and unsupported by javascript adapter either (org.keycloak.protocol.oidc.mappers.ClaimsParameterTokenMapper seem to be supporting more advanced claims parameter than "just" "acr" claim)