Using OpenID Connect (OIDC) and Keycloak to centralize authorization
Learn how to enable bearer token authorization in your Quarkus application using Keycloak Authorization Services for secure access to protected resources.
The quarkus-keycloak-authorization extension relies on quarkus-oidc.
It includes a policy enforcer that regulates access to secured resources.
Access is governed by permissions set in Keycloak.
Currently, this extension is compatible solely with Quarkus OIDC service applications.
It provides a flexible and dynamic authorization capability based on Resource-Based Access Control.
Rather than explicitly enforcing access through specific mechanisms such as role-based access control (RBAC), quarkus-keycloak-authorization determines request permissions based on resource attributes such as name, identifier, or Uniform Resource Identifier (URI).
This process involves sending a quarkus-oidc-verified bearer access token to Keycloak Authorization Services for an authorization decision.
Use quarkus-keycloak-authorization only if you work with Keycloak and have Keycloak Authorization Services enabled to make authorization decisions.
Use quarkus-oidc if you do not work with Keycloak or work with Keycloak but do not have its Keycloak Authorization Services enabled to make authorization decisions.
By shifting authorization responsibilities outside your application, you enhance security through various access control methods while eliminating the need for frequent re-deployments whenever security needs evolve. In this case, Keycloak acts as a centralized authorization hub, managing your protected resources and their corresponding permissions effectively.
For more information, see the OIDC Bearer token authentication guide.
It is important to realize that the Bearer token authentication mechanism does the authentication and creates a security identity.
Meanwhile, the quarkus-keycloak-authorization extension applies a Keycloak Authorization Policy to this identity based on the current request path and other policy settings.
For more information, see Keycloak Authorization Services documentation.
Requisitos previos
To complete this guide, you need:
-
Roughly 15 minutes
-
An IDE
-
JDK 17+ installed with
JAVA_HOMEconfigured appropriately -
Apache Maven 3.9.9
-
A working container runtime (Docker or Podman)
-
Optionally the Quarkus CLI if you want to use it
-
Optionally Mandrel or GraalVM installed and configured appropriately if you want to build a native executable (or Docker if you use a native container build)
Arquitectura
In this example, we build a very simple microservice that offers two endpoints:
-
/api/users/me -
/api/admin
These endpoints are protected. Access is granted only when a client sends a bearer token with the request. This token must be valid, having a correct signature, expiration date, and audience. Additionally, the microservice must trust the token.
The bearer token is issued by a Keycloak server and represents the subject for which the token was issued. For being an OAuth 2.0 Authorization Server, the token also references the client acting on behalf of the user.
The /api/users/me endpoint can be accessed by any user with a valid token.
As a response, it returns a JSON document with details about the user obtained from the information carried on the token.
This endpoint is protected with RBAC, and only users granted with the user role can access this endpoint.
The /api/admin endpoint is protected with RBAC, and only users granted the admin role can access it.
This is a very simple example of using RBAC policies to govern access to your resources. However, Keycloak supports other policies that you can use to perform even more fine-grained access control. By using this example, you’ll see that your application is completely decoupled from your authorization policies, with enforcement purely based on the accessed resource.
Solución
We recommend that you follow the instructions in the next sections and create the application step by step. However, you can go right to the completed example.
Clone el repositorio Git: git clone https://github.com/quarkusio/quarkus-quickstarts.git o descargue un archivo.
The solution is in the security-keycloak-authorization-quickstart directory.
Creating the project
En primer lugar, necesitamos un nuevo proyecto. Cree un nuevo proyecto con el siguiente comando:
For Windows users:
-
If using cmd, (don’t use backward slash
\and put everything on the same line) -
If using Powershell, wrap
-Dparameters in double quotes e.g."-DprojectArtifactId=security-keycloak-authorization-quickstart"
This command generates a project, importing the keycloak-authorization extension.
This extension implements a Keycloak Adapter for Quarkus applications and provides all the necessary capabilities to integrate with a Keycloak server and perform bearer token authorization.
If you already have your Quarkus project configured, you can add the oidc and keycloak-authorization extensions
to your project by running the following command in your project base directory:
quarkus extension add oidc,keycloak-authorization./mvnw quarkus:add-extension -Dextensions='oidc,keycloak-authorization'./gradlew addExtension --extensions='oidc,keycloak-authorization'This adds the following dependencies to your build file:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-oidc</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-keycloak-authorization</artifactId>
</dependency>implementation("io.quarkus:quarkus-oidc")
implementation("io.quarkus:quarkus-keycloak-authorization")Let’s start by implementing the /api/users/me endpoint.
As you can see in the following source code, it is a regular Jakarta REST resource:
package org.acme.security.keycloak.authorization;
import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import org.jboss.resteasy.reactive.NoCache;
import io.quarkus.security.identity.SecurityIdentity;
@Path("/api/users")
public class UsersResource {
@Inject
SecurityIdentity identity;
@GET
@Path("/me")
@NoCache
public User me() {
return new User(identity);
}
public static class User {
private final String userName;
User(SecurityIdentity identity) {
this.userName = identity.getPrincipal().getName();
}
public String getUserName() {
return userName;
}
}
}The source code for the /api/admin endpoint is also very simple:
package org.acme.security.keycloak.authorization;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
import io.quarkus.security.Authenticated;
@Path("/api/admin")
@Authenticated
public class AdminResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String admin() {
return "granted";
}
}Be aware that we have not defined annotations such as @RolesAllowed to explicitly enforce access to a resource.
Instead, the extension is responsible for mapping the URIs of the protected resources in Keycloak and evaluating the permissions accordingly, granting or denying access depending on the permissions granted by Keycloak.
Configuración de la aplicación
The OpenID Connect extension allows you to define the adapter configuration by using the application.properties file, which is usually located in the src/main/resources directory.
# OIDC Configuration
%prod.quarkus.oidc.auth-server-url=https://localhost:8543/realms/quarkus
quarkus.oidc.client-id=backend-service
quarkus.oidc.credentials.secret=secret
quarkus.oidc.tls.verification=none
# Enable Policy Enforcement
quarkus.keycloak.policy-enforcer.enable=true
# Tell Dev Services for Keycloak to import the realm file
# This property is not effective when running the application in JVM or native modes
quarkus.keycloak.devservices.realm-path=quarkus-realm.json
Adding a %prod. profile prefix to quarkus.oidc.auth-server-url ensures that Dev Services for Keycloak launches a container for you when the application is run in dev mode.
For more information, see the Running the application in Dev mode section.
|
By default, applications that use the quarkus-oidc extension are marked as a service type application (see quarkus.oidc.application-type).
This extension also supports only web-app type applications but only if the access token returned as part of the authorization code grant response is marked as a source of roles: quarkus.oidc.roles.source=accesstoken (web-app type applications check ID token roles by default).
|
Starting and configuring the Keycloak server
| Do not start the Keycloak server when you run the application in dev mode. Dev Services for Keycloak launches a container. For more information, see the Running the application in Dev mode section. |
To start a Keycloak server, use the following Docker command:
docker run --name keycloak -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin -p 8543:8443 -v "$(pwd)"/config/keycloak-keystore.jks:/etc/keycloak-keystore.jks quay.io/keycloak/keycloak:{keycloak.version} start --hostname-strict=false --https-key-store-file=/etc/keycloak-keystore.jkswhere keycloak.version must be 25.0.6 or later and the keycloak-keystore.jks can be found in quarkus-quickstarts/security-keycloak-authorization-quickstart/config.
Try to access your Keycloak server at localhost:8543.
To access the Keycloak Administration Console, log in as the admin user.
The username and password are both admin.
Import the realm configuration file to create a new realm. For more details, see the Keycloak documentation about how to create a new realm.
After importing the realm you can see the resource permissions:
It explains why the endpoint has no @RolesAllowed annotations - the resource access permissions are set directly in Keycloak.
Running the application in dev mode
To run the application in dev mode, use:
quarkus dev./mvnw quarkus:dev./gradlew --console=plain quarkusDevDev Services for Keycloak launches a Keycloak container and imports a quarkus-realm.json.
Open a Dev UI available at /q/dev-ui and click a Provider: Keycloak link in an OpenID Connect Dev UI card.
When asked to log in to a Single Page Application provided by OpenID Connect Dev UI:
-
Log in as
alice(password:alice), who only has aUser Permissionto access the/api/users/meresource:-
Access
/api/admin, which returns403. -
Access
/api/users/me, which returns200.
-
-
Log out and log in as
admin(password:admin), who has bothAdmin Permissionto access the/api/adminresource andUser Permissionto access the/api/users/meresource:-
Access
/api/admin, which returns200. -
Access
/api/users/me, which returns200.
-
If you have started Dev Services for Keycloak without importing a realm file such as quarkus-realm.json that is already configured to support Keycloak Authorization, create a default quarkus realm without Keycloak authorization policies.
In this case, you must select the Keycloak Admin link in the OpenId Connect Dev UI card and configure Keycloak Authorization Services in the default quarkus realm.
The Keycloak Admin link is easy to find in Dev UI:
When logging into the Keycloak admin console, the username and password are both admin.
If your application uses Keycloak authorization configured with JavaScript policies that are deployed in a JAR file, you can set up Dev Services for Keycloak to transfer this archive to the Keycloak container. For instance:
quarkus.keycloak.devservices.resource-aliases.policies=/policies.jar (1)
quarkus.keycloak.devservices.resource-mappings.policies=/opt/keycloak/providers/policies.jar (2)| 1 | policies alias is created for the /policies.jar classpath resource.
Policy archive can also be located in the file system. |
| 2 | The policies archive is mapped to the /opt/keycloak/providers/policies.jar container location. |
Running the application in JVM mode
After exploring the application in dev mode, you can run it as a standard Java application.
First compile it:
quarkus build./mvnw install./gradlew buildThen run it:
java -jar target/quarkus-app/quarkus-run.jarRunning the application in native mode
This same demo can be compiled into native code; no modifications are required.
This implies that you no longer need to install a JVM on your production environment because the runtime technology is included in the produced binary and optimized to run with minimal resources.
Compilation takes a bit longer, so this step is turned off by default; let’s build again by enabling the native profile:
quarkus build --native./mvnw install -Dnative./gradlew build -Dquarkus.native.enabled=trueAfter a while, you can run this binary directly:
./target/security-keycloak-authorization-quickstart-runnerTesting the application
See the preceding Running the application in Dev mode section about testing your application in a dev mode.
You can test the application launched in JVM or native modes with curl.
The application uses bearer token authorization, and the first thing to do is obtain an access token from the Keycloak server to access the application resources:
export access_token=$(\
curl --insecure -X POST https://localhost:8543/realms/quarkus/protocol/openid-connect/token \
--user backend-service:secret \
-H 'content-type: application/x-www-form-urlencoded' \
-d 'username=alice&password=alice&grant_type=password' | jq --raw-output '.access_token' \
)|
When the |
The preceding example obtains an access token for user alice.
Any user is allowed to access the
http://localhost:8080/api/users/me endpoint,
which returns a JSON payload with details about the user.
curl -v -X GET \
http://localhost:8080/api/users/me \
-H "Authorization: Bearer "$access_tokenThe http://localhost:8080/api/admin endpoint can only be accessed by users with the admin role.
If you try to access this endpoint with the previously issued access token, you get a 403 response from the server.
curl -v -X GET \
http://localhost:8080/api/admin \
-H "Authorization: Bearer "$access_tokenTo access the admin endpoint, get a token for the admin user:
export access_token=$(\
curl --insecure -X POST https://localhost:8543/realms/quarkus/protocol/openid-connect/token \
--user backend-service:secret \
-H 'content-type: application/x-www-form-urlencoded' \
-d 'username=admin&password=admin&grant_type=password' | jq --raw-output '.access_token' \
)Injecting the authorization client
In some cases, using the Keycloak Authorization Client Java API is beneficial for tasks such as managing resources and obtaining permissions directly from Keycloak.
For this purpose, you can inject an AuthzClient instance into your beans as follows:
public class ProtectedResource {
@Inject
AuthzClient authzClient;
}
If you want to use the AuthzClient directly, set quarkus.keycloak.policy-enforcer.enable=true; otherwise, no bean is available for injection.
|
Mapping protected resources
By default, the extension fetches resources on-demand from Keycloak, using their URI to identify and map the resources in your application that need to be protected.
To disable this on-demand fetching and instead pre-load resources at startup, apply the following configuration setting:
quarkus.keycloak.policy-enforcer.lazy-load-paths=falseThe time required to pre-load resources from Keycloak at startup varies based on their quantity, potentially affecting your application’s initial load time."
More about configuring protected resources
In the default configuration, Keycloak manages the roles and decides who can access which routes.
To configure the protected routes by using the @RolesAllowed annotation or the application.properties file, check the OpenID Connect (OIDC) Bearer token authentication and Authorization of web endpoints guides.
For more details, check the Quarkus Security overview.
Access to public resources
To enable access to a public resource without the quarkus-keycloak-authorization applying its policies, create a permit HTTP Policy configuration in application.properties.
For more information, see the Authorization of web endpoints guide.
There’s no need to deactivate policy checks for a Keycloak Authorization Policy with settings such as these:
quarkus.keycloak.policy-enforcer.paths.1.paths=/api/public
quarkus.keycloak.policy-enforcer.paths.1.enforcement-mode=DISABLEDTo block access to the public resource to anonymous users, you can create an enforcing Keycloak Authorization Policy:
quarkus.keycloak.policy-enforcer.paths.1.paths=/api/public-enforcing
quarkus.keycloak.policy-enforcer.paths.1.enforcement-mode=ENFORCINGOnly the default tenant configuration applies when controlling anonymous access to the public resource is required.
Checking permission scopes programmatically
In addition to resource permissions, you can specify method scopes. The scope usually represents an action that can be performed on a resource. You can create an enforcing Keycloak Authorization Policy with a method scope. For example:
# path policy with enforced scope 'read' for method 'GET'
quarkus.keycloak.policy-enforcer.paths.1.name=Scope Permission Resource
quarkus.keycloak.policy-enforcer.paths.1.paths=/api/protected/standard-way
quarkus.keycloak.policy-enforcer.paths.1.methods.get.method=GET
quarkus.keycloak.policy-enforcer.paths.1.methods.get.scopes=read (1)
# path policies without scope
quarkus.keycloak.policy-enforcer.paths.2.name=Scope Permission Resource
quarkus.keycloak.policy-enforcer.paths.2.paths=/api/protected/programmatic-way,/api/protected/annotation-way| 1 | User must have resource permission 'Scope Permission Resource' and scope 'read' |
The Keycloak Policy Enforcer now secures the /api/protected/standard-way request path, eliminating the need for additional annotations such as @RolesAllowed.
However, in certain scenarios, a programmatic check is necessary.
You can achieve this by injecting a SecurityIdentity instance into your beans, as shown in the following example.
Or, you can get the same result by annotating the resource method with @PermissionsAllowed.
The following example demonstrates three resource methods, each requiring the same read scope:
import java.security.BasicPermission;
import java.util.List;
import jakarta.inject.Inject;
import jakarta.ws.rs.ForbiddenException;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import org.keycloak.representations.idm.authorization.Permission;
import io.quarkus.security.PermissionsAllowed;
import io.quarkus.security.identity.SecurityIdentity;
import io.smallrye.mutiny.Uni;
@Path("/api/protected")
public class ProtectedResource {
@Inject
SecurityIdentity identity;
@GET
@Path("/standard-way")
public Uni<List<Permission>> standardWay() { (1)
return Uni.createFrom().item(identity.<List<Permission>> getAttribute("permissions"));
}
@GET
@Path("/programmatic-way")
public Uni<List<Permission>> programmaticWay() {
var requiredPermission = new BasicPermission("Scope Permission Resource") {
@Override
public String getActions() {
return "read";
}
};
return identity.checkPermission(requiredPermission).onItem() (2)
.transform(granted -> {
if (granted) {
return identity.getAttribute("permissions");
}
throw new ForbiddenException();
});
}
@PermissionsAllowed("Scope Permission Resource:read") (3)
@GET
@Path("/annotation-way")
public Uni<List<Permission>> annotationWay() {
return Uni.createFrom().item(identity.<List<Permission>> getAttribute("permissions"));
}
}| 1 | Request sub-path /standard-way requires both resource permission and scope read according to the configuration properties we previously set in the application.properties. |
| 2 | Request sub-path /programmatic-way only requires permission Scope Permission Resource, but we can enforce scope with SecurityIdentity#checkPermission. |
| 3 | The @PermissionsAllowed annotation only grants access to the requests with permission Scope Permission Resource and scope read.
For more information, see the section Authorization using annotations of the Security Authorization guide. |
Multi-tenancy
You can set up policy enforcer configurations for each tenant, similar to how it is done with OpenID Connect (OIDC) multi-tenancy.
For example:
quarkus.keycloak.policy-enforcer.enable=true
# Default Tenant
quarkus.oidc.auth-server-url=${keycloak.url:replaced-by-test-resource}/realms/quarkus
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.secret=secret
quarkus.keycloak.policy-enforcer.enforcement-mode=PERMISSIVE
quarkus.keycloak.policy-enforcer.paths.1.name=Permission Resource
quarkus.keycloak.policy-enforcer.paths.1.paths=/api/permission
quarkus.keycloak.policy-enforcer.paths.1.claim-information-point.claims.static-claim=static-claim
# Service Tenant
quarkus.oidc.service-tenant.auth-server-url=${keycloak.url:replaced-by-test-resource}/realms/quarkus
quarkus.oidc.service-tenant.client-id=quarkus-app
quarkus.oidc.service-tenant.credentials.secret=secret
quarkus.keycloak.service-tenant.policy-enforcer.enforcement-mode=PERMISSIVE
quarkus.keycloak.service-tenant.policy-enforcer.paths.1.name=Permission Resource Service
quarkus.keycloak.service-tenant.policy-enforcer.paths.1.paths=/api/permission
quarkus.keycloak.service-tenant.policy-enforcer.paths.1.claim-information-point.claims.static-claim=static-claim
# WebApp Tenant
quarkus.oidc.webapp-tenant.auth-server-url=${keycloak.url:replaced-by-test-resource}/realms/quarkus
quarkus.oidc.webapp-tenant.client-id=quarkus-app
quarkus.oidc.webapp-tenant.credentials.secret=secret
quarkus.oidc.webapp-tenant.application-type=web-app
quarkus.oidc.webapp-tenant.roles.source=accesstoken
quarkus.keycloak.webapp-tenant.policy-enforcer.enforcement-mode=PERMISSIVE
quarkus.keycloak.webapp-tenant.policy-enforcer.paths.1.name=Permission Resource WebApp
quarkus.keycloak.webapp-tenant.policy-enforcer.paths.1.paths=/api/permission
quarkus.keycloak.webapp-tenant.policy-enforcer.paths.1.claim-information-point.claims.static-claim=static-claimDynamic tenant configuration resolution
If you need a more dynamic configuration for the different tenants you want to support and don’t want to end up
with multiple entries in your configuration file, you can use the io.quarkus.keycloak.pep.TenantPolicyConfigResolver.
This interface allows you to dynamically create tenant configurations at runtime:
package org.acme.security.keycloak.authorization;
import java.util.Map;
import jakarta.enterprise.context.ApplicationScoped;
import io.quarkus.keycloak.pep.TenantPolicyConfigResolver;
import io.quarkus.keycloak.pep.runtime.KeycloakPolicyEnforcerConfig;
import io.quarkus.keycloak.pep.runtime.KeycloakPolicyEnforcerTenantConfig;
import io.quarkus.oidc.OidcRequestContext;
import io.quarkus.oidc.OidcTenantConfig;
import io.smallrye.mutiny.Uni;
import io.vertx.ext.web.RoutingContext;
@ApplicationScoped
public class CustomTenantPolicyConfigResolver implements TenantPolicyConfigResolver {
private final KeycloakPolicyEnforcerTenantConfig enhancedTenantConfig;
private final KeycloakPolicyEnforcerTenantConfig newTenantConfig;
public CustomTenantPolicyConfigResolver(KeycloakPolicyEnforcerConfig enforcerConfig) {
this.enhancedTenantConfig = KeycloakPolicyEnforcerTenantConfig.builder(config) (1)
.paths("/enhanced-config")
.permissionName("Permission Name")
.get("read-scope")
.build();
this.newTenantConfig = KeycloakPolicyEnforcerTenantConfig.builder() (2)
.paths("/new-config")
.claimInformationPoint(Map.of("claims", Map.of("grant", "{request.parameter['grant']}")))
.build();
}
@Override
public Uni<KeycloakPolicyEnforcerTenantConfig> resolve(RoutingContext routingContext, OidcTenantConfig tenantConfig,
OidcRequestContext<KeycloakPolicyEnforcerTenantConfig> requestContext) {
String path = routingContext.normalizedPath();
String tenantId = tenantConfig.tenantId.orElse(null);
if ("enhanced-config-tenant".equals(tenantId) && path.equals("/enhanced-config")) {
return Uni.createFrom().item(enhancedTenantConfig);
} else if ("new-config-tenant".equals(tenantId) && path.equals("/new-config")) {
return Uni.createFrom().item(newTenantConfig);
}
return Uni.createFrom().nullItem(); (3)
}
}| 1 | Create or update the /enhanced-config path in the default tenant config. |
| 2 | Add /new-config path into tenant config populated with documented configuration default values. |
| 3 | Use default static tenant configuration resolution based on the application.properties file and other SmallRye Config configuration sources. |
Referencia de configuración
This configuration adheres to the official Keycloak Policy Enforcer Configuration guidelines. For detailed insights into various configuration options, see the following documentation:
Propiedad de configuración fijada en tiempo de compilación - Todas las demás propiedades de configuración son anulables en tiempo de ejecución
Configuration property |
Tipo |
Por defecto |
|---|---|---|
Enables policy enforcement. Environment variable: Show more |
boolean |
|
Adapters will make separate HTTP invocations to the Keycloak server to turn an access code into an access token. This config option defines how many connections to the Keycloak server should be pooled Environment variable: Show more |
int |
|
Specifies how policies are enforced. Environment variable: Show more |
|
|
Defines the limit of entries that should be kept in the cache Environment variable: Show more |
int |
|
Defines the time in milliseconds when the entry should be expired Environment variable: Show more |
long |
|
Specifies how the adapter should fetch the server for resources associated with paths in your application. If true, the policy enforcer is going to fetch resources on-demand accordingly with the path being requested Environment variable: Show more |
boolean |
|
Complex config. Environment variable: Show more |
Map<String,Map<String,Map<String,String>>> |
|
Simple config. Environment variable: Show more |
Map<String,Map<String,String>> |
|
Specifies how scopes should be mapped to HTTP methods. If set to true, the policy enforcer will use the HTTP method from the current request to check whether access should be granted Environment variable: Show more |
boolean |
|
The name of a resource on the server that is to be associated with a given path Environment variable: Show more |
string |
|
HTTP request paths that should be protected by the policy enforcer Environment variable: Show more |
list of string |
|
The name of the HTTP method Environment variable: Show more |
string |
required |
An array of strings with the scopes associated with the method Environment variable: Show more |
list of string |
required |
A string referencing the enforcement mode for the scopes associated with a method Environment variable: Show more |
|
|
Specifies how policies are enforced Environment variable: Show more |
|
|
Complex config. Environment variable: Show more |
Map<String,Map<String,Map<String,String>>> |
|
Simple config. Environment variable: Show more |
Map<String,Map<String,String>> |
|
Tipo |
Por defecto |
|
Adapters will make separate HTTP invocations to the Keycloak server to turn an access code into an access token. This config option defines how many connections to the Keycloak server should be pooled Environment variable: Show more |
int |
|
Specifies how policies are enforced. Environment variable: Show more |
|
|
The name of a resource on the server that is to be associated with a given path Environment variable: Show more |
string |
|
HTTP request paths that should be protected by the policy enforcer Environment variable: Show more |
list of string |
|
The name of the HTTP method Environment variable: Show more |
string |
required |
An array of strings with the scopes associated with the method Environment variable: Show more |
list of string |
required |
A string referencing the enforcement mode for the scopes associated with a method Environment variable: Show more |
|
|
Specifies how policies are enforced Environment variable: Show more |
|
|
Complex config. Environment variable: Show more |
Map<String,Map<String,Map<String,String>>> |
|
Simple config. Environment variable: Show more |
Map<String,Map<String,String>> |
|
Defines the limit of entries that should be kept in the cache Environment variable: Show more |
int |
|
Defines the time in milliseconds when the entry should be expired Environment variable: Show more |
long |
|
Specifies how the adapter should fetch the server for resources associated with paths in your application. If true, the policy enforcer is going to fetch resources on-demand accordingly with the path being requested Environment variable: Show more |
boolean |
|
Complex config. Environment variable: Show more |
Map<String,Map<String,Map<String,String>>> |
|
Simple config. Environment variable: Show more |
Map<String,Map<String,String>> |
|
Specifies how scopes should be mapped to HTTP methods. If set to true, the policy enforcer will use the HTTP method from the current request to check whether access should be granted Environment variable: Show more |
boolean |
|
