PKCE in keycloak-servlet-oauth-client does not work
by 乗松隆志 / NORIMATSU，TAKASHI
Hello,
I had contributed server side PKCE (RFC 7636 Proof Key for Code Exchange) support for keycloak and merged.
At that time, I had also implemented client side PKCE in servlet oauth client to demonstrate how PKCE works.
However, it seemed that I had pushed servlet oauth client codes that did not work instead of ones used in my local environment.
Therefore, client side PKCE in servlet oauth client does not work.
I've already known how to fix it, but it is difficult to write Arquillian integration tests.
I've searched existing Arquillian integration tests for servlet oauth client but not found.
Could anyone help me?
Best regards,
Takashi Norimatsu
Hitachi Ltd.,
5 years, 9 months
Deprecating/Removing keycloak-servlet-oauth-client
by Marek Posolda
We plan to deprecate and then eventually remove
keycloak-servlet-oauth-client. We don't officially support this client
(it is not documented and tested) and it is additional maintenance
overhead to have it in our codebase. Is someone around, who uses this
client? Do you want to become a maintainer of it? If yes, let us know.
You can fork it to your repository and we will reference it from the
"Extensions" page [1].
Some more details about the client:
AFAIR it is one of the very early-days keycloak features and the
use-case behind this was, that you have web frontend java application,
which is not secured by Keycloak and doesn't use adapter. But you still
want to have a way to invoke the REST services from this application,
which are secured by Keycloak. So you want to trigger the OAuth flow
manually from the Java without having the adapter to do it for you -
that's what this client is doing.
I think that this client can be almost always replaced by adapter or by
the servlet filter. The only case when it couldn't be replaced by
servlet filter is, when you have non-servlet java application.
This OAuth client is unmaintained and it is missing lot of features,
which were recently added to the adapter.
[1] https://www.keycloak.org/extensions.html
Marek
5 years, 9 months
OIDC session management, front/back channel logout specifications soon to be finalised
by Stian Thorgersen
FIY all 3 specifications in $sub are on track to be finalised soon.
Session management - we're mostly here I believe, but need to run
conformance tests
Front-channel - we don't have this, so contributions would be welcome
Back-channel - we have something similar, but doesn't follow the spec. So
we need to fix this. Could introduce a new endpoint that is spec compliant
and deprecate the old. Or we morph the old endpoint into the new, which may
be more awkward for users, so my vote goes to new compliant endpoint.
5 years, 9 months
Implementation of Front-Channel Logout for OpenID Connect clients
by Diego Liberalquino
Hello,
A thing that bothers me on Keycloak is the lack of implementation of
Front-Channel Logout for OpenID Clients. Is there any technical reason for
this or is just awaiting a community contribution? I mean, the spec is
supported for SAML clients, and it also works for external OIDC providers.
Best regards,
Diego Liberalquino
5 years, 9 months
Provisioning of Keycloak deployments
by Tomas Kyjovsky
Looking at the feedback in the questionare, there are several requests to make provisioning and configuration of KC deployments easier.
I was also thinking about this in relation to our testsuite for a while, and whether there should be a separate module for this. Either inside the testsuite module, or possibly even in the projecr root - in case we want it to be usable both by the testsuite (via API) and manually, by people who want to deploy Keycloak and other interacting sevices somewhere in their cloud or kubernetes/openshift cluster.
Another option would be to create an entirely separate project (akin to jboss-dockerfiles/keycloak [1] or the Kubernetes Helm project [2]) which could even support multiple versions of Keycloak and other components. Perhaps some install/upgrade wizzards and examples could be put there. Not sure how an external project would be usable with the testsuite though. The question is to what extent these two use cases are even compatible (devops/maintenance vs extensive integration testing). Benefit of combining both use cases would be reusing common stuff (DRY).
In the testsuite we currently use 2 different solutions:
1) Integration testsuite uses Maven/Ant/JBossCLI to prepare configurations on local FS and then manages lifecycle of all components through Arquillian. Additionally there are testsuite-specific server extensions and custom test apps.
2) Performance testsuite uses Maven/Ant/JBossCLI to prepare configurations on local FS and then uses Docker Compose to build and orchestrate the services. The tests then run against a "remote" provisioned system.
There is also a PR from Radim Vansa who created a provisioning solution for OpenShift a while ago, which I have yet to review and merge.
And we need to add some bare-metal provisioning option for testing in bare-metal labs (probably ansible).
I think all of these different solutions could be put under one roof.
Maybe something like this:
keycloak/
...
core/
adapters/
model/
examples/
...
distribution/
provisioning/
provisioning-api/
provisioner-local/
provisioner-docker/
provisioner-openshift/
provisioner-ansible/
...
testsuite/
integration/
performance/
Or like this, if just inside the testsuite:
keycloak/
...
testsuite/
provisioning/
integration/
performance/
The provisioning API would have a simple interface:
interface Provisioner {
List<String> getConfiguredServices();
void buildService(String service);
void startService(String service);
void stopService(String service);
}
Particular provisioner module would the look something like this:
provisioner-X/
src/main/
java/.../ProvisionerX.java (wrapper for external provisioning tool or API)
resources/... (for exmple jboss-cli scripts, dockerfiles, ansible playbooks, etc.)
pom.xml/<profiles>/
server
server-db-vendor-1
server-db-vendor-2
...
server-ldap-vendor-1
server-ldap-vendor-2
...
server-cache
server-load-balancer
client-set-1
client-set-2
client-set-3
...
webdriver-vendor-1/
webdriver-vendor-2/
...
The process would consist of:
1) Configuring required provisioner modules:
- user provides connection parameters and credentials if needed (kubernetes/openshift, ssh keys for anisble, etc.)
- user provides configuration parameters for services
2) Building required provisioner modules:
- building provisioning module will prepare all local artifacts which will be needed for running methods of the Provisioner interface
- after module is built the provisioner implementation/wrapper will be runnable directly with Java or indirectly from script (this would be useful the dev-ops scenario)
- also the external provisioning tool (such as docker-compose or ansible) will be runnable directly at this point
3) Running the testsuite. The testsuite delegates to the API to spin up or tear down the services as needed.
The integration testsuite would default to the `provisioner-local` module which would just contain stuff which is now located in: testsuite/integration-arquillian/servers.
But it could be instructed to use a different provisioning module(s).
It would be nice if individual services or sets of services could be combined across different provisioners, and if this would also allow for integration of externally provided services such as existing DB servers.
That's the general idea. I've brought this up once before but it was never a priority. Maybe it's time to consider it again and let everyone chip in with their ideas.
I think this consolidation would be useful at least within the testsuite. It is also kind of related to the microservice-oriented testing approach which I mentioned in my previous post.
Regards,
Tomas
[1] https://github.com/jboss-dockerfiles/keycloak
[2] https://github.com/helm/charts/tree/master/stable/keycloak
5 years, 9 months
Allow access_type parameter to be sent to Google Identity Provider
by Francesco Degrassi
Hello,
we're testing Keycloak with Google as a social identity provider and using
the token exchange functionality to get access to the IDP access token.
I noticed that Google requires the access_type parameter to be set to
"offline" in the call to the authorization endpoint to release a refresh
token, but there is no easy way to do this in Keycloak; configuring a
generic OIDC identity provider allows me to configure access_type as a
forwarded parameter, but no such option exists using GoogleIdentityProvider.
I have a patch that (a) modifies GoogleIdentityProviderConfig and overrides
getForwardedParameters() to add "access_type" to the returned values.
Other options I considered include (b) changing the UI to allow to
configure the forwareded parameters for GoogleIdentityProvider (since it
extends OidcIdentityProvider) or (c) add a boolean configuration option to
GoogleIdentityProviderConfig to allow/disallow forwarding the parameter or
(d) add a boolean configuration option to GoogleIdentityProviderConfig to
set "access_type" to "offline" if checked.
Which would be the preferred route? Would a pull request be accepted?
Cheers.
*Francesco Degrassi*
Tech Lead
+39 329 4128 422 <+39+329+4128+422>
*OptionFactory <http://www.optionfactory.net/>*
5 years, 9 months
Allow AdminEvents for custom resource types
by Lösch, Sebastian
Hello devs,
we implemented a custom resource type as an extension to keycloak.
For traceability reasons we would like to track actions for this custom resource type via AdminEvents.
Unfortunately the resource type is represented by the enum ResourceType. Therefore no AdminEvents for custom non standard resource types can be created.
It would be nice if it is possible to specify the resource type as string value also.
This is only a small change, because the resource type is only provided via enum but handled as string value internally.
I provided a pull request for that enhancement: https://github.com/keycloak/keycloak/pull/5882
May anybody have a look on that review?
Best regards,
Sebastian
5 years, 9 months
jaxrs-oauth-client deprecation question
by Chris Downs
Hello!
I noticed that jaxrs-oauth-client is marked as deprecated in master. Is
this deprecation in favor of something better, or do you just not want
to maintain it anymore? Asking because I'm adding keycloak authn/z to a
dropwizard jaxrs project which was going to be based off of this, but
don't want to move forward with something that is going away if there is
a better option.
Thanks,
Chris Downs
5 years, 9 months
IDP Refresh token lost on first refresh during internal to external token exchange
by Francesco Degrassi
When performing an internal to external token exchange, if the requested
IDP access token is expired, Keycloak performs a token refresh using the
originally obtained access token.
After the operation is complete, the original token response is discarded
and the new one is saved; unless the new one includes a refresh token, the
refresh token is then lost and subsequent token exchanges requiring an IDP
token refresh will fail.
This happens regularly with Google as an IDP, since the token refresh
response does not include a refresh token, which is only provided in the
original authorization code exchange.
I have a patch to OidcIdentityProvider which ensures that the original
refresh token is saved if a new one has not been provided during the token
refresh operation. Should I proceed and provide a PR?
Cheers.
*Francesco Degrassi*
Tech Lead
+39 329 4128 422 <+39+329+4128+422>
*OptionFactory <http://www.optionfactory.net/>*
5 years, 9 months
