For instance, we introduced quarkus.http.root-path as the counterpart of quarkus.servlet.context-path .

Please reach out to us if you think a missing feature should be supported out of the box by RESTEasy + Vert.x because we want as many users as possible on the new Vert.x layer.

For most applications this should be largely transparent, however if you wish to use Servlet filters or other Servlet functionality then you can simply add a dependency on quarkus-undertow . If Undertow is present, RESTEasy will detect this and will fall back to running as a Servlet.

This means that if your application depends on quarkus-resteasy and not quarkus-undertow then Servlet will not be present, and RESTEasy will run directly on a Vert.x backend.

HTTP form auth is missing in this release, it will be replaced sometime next week. Previously this relied on an in-memory HTTP session, so did not work in cloud environments. The new implementation will use encrypted cookies to replace the in memory session allowing it to be used in clustered environments.

HTTP basic auth is now enabled by the quarkus.http-auth.basic=true property. To use this, you will need to have the elytron-security-properties-file or the (still alpha) elytron-security-jdbc extension in your application.

There is a new elytron-security-jdbc extension that allows for users to be loaded from a database. This extension is still alpha and its configuration will likely be simplified for the next release.

The elytron-security extension has been broken up into base functionality and a new elytron-security-properties-file extension that contains support for simple properties file based config.

HTTP Authentication is now handled at the Vert.x layer. Previously this was configured in the Elytron extensions, this configuration has been removed

This is still a work in progress and there is a lot more work to come over the following few weeks, however the main changes today are:

Previously Security was tied to Undertow and only applied to Servlet deployments, while also being 100% blocking. This change brings in a new security layer that is not tied to any specific implementation, and also allows for reactive security operations to integrate with Vert.x. It is also no longer tied to Elytron, however Elytron still remains an option.

Keycloak extension replaced by an OIDC extension (OpenID Connect)

The original Keycloak-specific quarkus-keycloak adapter has been replaced with a generic OpenID Connect (OIDC) quarkus-oidc adapter which will provide a comprehensive, generic and reactive support for the most important OIDC flows and be able to verify the tokens from all the certified OIDC providers including Keycloak. Tokens from the other OIDC and OAuth2 providers implementing a token introspection endpoint will also be recognized.

You can find all the information relative to this new extension in our new OIDC guide but here is a summary of the changes that will probably affect you.

Note that the configuration namespace has changed from quarkus.keycloak to quarkus.oidc . The realm property has been removed and the Keycloak users are now required to configure the auth-base-url as follows:

quarkus.oidc.auth-base-url = http://myorg.keycloak.com/realms/{realm}

where {realm} represents a Keycloak realm.

resource has been renamed to client-id . realm-public-key has been renamed to public-key .

Multi-tenancy support based on KeycloakConfigResolver is no longer supported with a Vert.x OAuth2 based alternative mechanism to be introduced in the next release.

Users needing to configure CORS should now use Quarkus CORS filter.

The team appreciates that some of the original quarkus-keycloak users may be affected by this change and would like to assure the community that quarkus-oidc will offer an equivalent but also significantly better overall OIDC experience very soon.