Fix incorrect source format
This commit is contained in:
k-tamura
Stian Thorgersen
parent
c8c7a7cebe
commit
bf74b61e8b
35 changed files with 56 additions and 48 deletions
|
|
@ -60,7 +60,7 @@ Most applications should use the `onGrant` callback to retry a request after a 4
|
|||
|
||||
The keycloak-authz.js library provides an `entitlement` function that you can use to obtain an RPT from the server using the Entitlement API.
|
||||
|
||||
```json
|
||||
```javascript
|
||||
authorization.entitlement('my-resource-server-id').then(function (rpt) {
|
||||
// onGrant callback function.
|
||||
// If authorization was successful you'll receive an RPT
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ image:{project_images}/resource-server/client-create.png[alt="Create Client"]
|
|||
. Type the `Client ID` of the client. For example, _my-resource-server_.
|
||||
. Type the `Root URL` for your application. For example:
|
||||
+
|
||||
```bash
|
||||
```
|
||||
http://${host}:${port}/my-resource-server
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ This token consists of all the permissions granted to a user as a result of the
|
|||
With an RPT, client applications can gain access to protected resources at the resource server.
|
||||
|
||||
.UMA compliant Authorization API Endpoint
|
||||
```bash
|
||||
```
|
||||
http://${host}:${port}/auth/realms/${realm_name}/authz/authorize
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ This token consists of all the entitlements (or permissions) for a user as a res
|
|||
With an RPT, client applications can gain access to protected resources at the resource server.
|
||||
|
||||
.Entitlement API Endpoint
|
||||
```bash
|
||||
```
|
||||
http://${host}:${port}/auth/realms/${realm_name}/authz/entitlement/{client_id}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
Resource servers using the UMA protocol can use a specific endpoint to manage permission requests. This endpoint provides a UMA-compliant flow for registering permission requests and obtaining a permission ticket.
|
||||
|
||||
```bash
|
||||
```
|
||||
http://${host}:${port}/auth/realms/${realm_name}/authz/protection/permission
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
Resource servers can manage their resources remotely using a UMA-compliant endpoint.
|
||||
|
||||
```bash
|
||||
```
|
||||
http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
Resource servers can manage their resources remotely using a UMA-compliant endpoint.
|
||||
|
||||
```bash
|
||||
```
|
||||
http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ curl -X POST \
|
|||
|
||||
The example above is using the *client_credentials* grant type to obtain a PAT from the server. As a result, the server returns a response similar to the following:
|
||||
|
||||
```bash
|
||||
```json
|
||||
{
|
||||
"access_token": ${PAT},
|
||||
"expires_in": 300,
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ There are two main use cases where token introspection can help you:
|
|||
|
||||
The token introspection is essentially a https://tools.ietf.org/html/rfc7662[OAuth2 token introspection]-compliant endpoint from which you can obtain information about an RPT.
|
||||
|
||||
```bash
|
||||
```
|
||||
http://${host}:${port}/auth/realms/${realm_name}/protocol/openid-connect/token/introspect
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ Sending startup registrations and periodic re-registration is disabled by defaul
|
|||
|
||||
To enable the feature edit the `WEB-INF/keycloak.json` file for your application and add:
|
||||
|
||||
[source]
|
||||
[source,json]
|
||||
----
|
||||
"register-node-at-startup": true,
|
||||
"register-node-period": 600,
|
||||
|
|
@ -105,7 +105,7 @@ request. This may have a performance impact as your application will send more r
|
|||
|
||||
To enable the feature edit the `WEB-INF/keycloak.json` file for your application and add:
|
||||
|
||||
[source]
|
||||
[source,json]
|
||||
----
|
||||
"always-refresh-token": true
|
||||
----
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ This is the traditional method described in the OAuth2 specification. The client
|
|||
You can generate the secret for a particular client in the {project_name} administration console, and then paste this secret into the `keycloak.json` file on the application side:
|
||||
|
||||
|
||||
[source]
|
||||
[source,json]
|
||||
----
|
||||
"credentials": {
|
||||
"secret": "19666a4f-32dd-4049-b082-684c74115f28"
|
||||
|
|
@ -36,7 +36,7 @@ For more details on how to set up the {project_name} administration console see
|
|||
|
||||
For set up on the adapter side you need to have something like this in your `keycloak.json` file:
|
||||
|
||||
[source]
|
||||
[source,json]
|
||||
----
|
||||
"credentials": {
|
||||
"jwt": {
|
||||
|
|
@ -62,7 +62,7 @@ This is the same as Client Authentication with Signed JWT except for using the c
|
|||
|
||||
The client has a secret, which needs to be known to both the adapter (application) and the {project_name} server. You need to choose `Signed JWT with Client Secret` as the method of authenticating your client in the tab `Credentials` in administration console, and then paste this secret into the `keycloak.json` file on the application side:
|
||||
|
||||
[source]
|
||||
[source,json]
|
||||
----
|
||||
"credentials": {
|
||||
"secret-jwt": {
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ To run Hawtio on the {fuseHawtioEAPVersion} server, complete the following steps
|
|||
|
||||
. Restart the {fuseHawtioEAPVersion} server with Hawtio:
|
||||
+
|
||||
[source,xml]
|
||||
[source,bash]
|
||||
----
|
||||
cd $EAP_HOME/bin
|
||||
./standalone.sh -Djboss.socket.binding.port-offset=101
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ through the `KeycloakInstalled` constructor.
|
|||
In the example below, the client configuration for `desktop-app`
|
||||
uses the following `keycloak.json`:
|
||||
|
||||
[source]
|
||||
[source,json]
|
||||
----
|
||||
|
||||
{
|
||||
|
|
@ -82,7 +82,7 @@ uses the following `keycloak.json`:
|
|||
----
|
||||
|
||||
the following sketch demonstrates working with the `KeycloakInstalled` adapter:
|
||||
[source]
|
||||
[source,java]
|
||||
----
|
||||
|
||||
// reads the configuration from classpath: META-INF/keycloak.json
|
||||
|
|
@ -111,7 +111,7 @@ login / logout requests via the `loginResponseWriter` and `logoutResponseWriter`
|
|||
|
||||
The following provides an example for the configuration mentioned above.
|
||||
|
||||
[source]
|
||||
[source,java]
|
||||
----
|
||||
import java.util.Locale;
|
||||
import java.util.concurrent.Executors;
|
||||
|
|
|
|||
|
|
@ -298,7 +298,7 @@ If you have multiple deployments secured by the same realm you can share the rea
|
|||
To propagate the security context to the EJB tier you need to configure it to use the "keycloak" security domain. This
|
||||
can be achieved with the @SecurityDomain annotation:
|
||||
|
||||
[source]
|
||||
[source,java]
|
||||
----
|
||||
|
||||
import org.jboss.ejb3.annotation.SecurityDomain;
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ Finally you must specify both a `login-config` and use standard servlet security
|
|||
Here's an example:
|
||||
|
||||
|
||||
[source]
|
||||
[source,xml]
|
||||
----
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ The implementation allows customization by overriding methods.
|
|||
While its use is not required, it greatly simplifies your security context configuration.
|
||||
|
||||
|
||||
[source]
|
||||
[source,java]
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ for the {project_name} adapter.
|
|||
While Spring Security's XML namespace simplifies configuration, customizing the configuration can be a bit verbose.
|
||||
|
||||
|
||||
[source]
|
||||
[source,xml]
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -171,7 +171,7 @@ To enable this feature your security configuration must add the `KeycloakRestTem
|
|||
Note that it must be scoped as a prototype to function correctly.
|
||||
|
||||
For Java configuration:
|
||||
[source]
|
||||
[source,java]
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -196,7 +196,7 @@ public class SecurityConfig extends KeycloakWebSecurityConfigurerAdapter {
|
|||
----
|
||||
|
||||
For XML configuration:
|
||||
[source]
|
||||
[source,xml]
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -207,7 +207,7 @@ For XML configuration:
|
|||
|
||||
Your application code can then use `KeycloakRestTemplate` any time it needs to make a call to another client.
|
||||
For example:
|
||||
[source]
|
||||
[source,java]
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -234,7 +234,7 @@ The Spring Boot and the Spring Security adapters can be combined.
|
|||
|
||||
If you are using the Keycloak Spring Boot Starter to make use of the Spring Security adapter you just need to add the Spring Security starter :
|
||||
|
||||
[source]
|
||||
[source,xml]
|
||||
----
|
||||
|
||||
<dependency>
|
||||
|
|
@ -248,7 +248,7 @@ If you are using the Keycloak Spring Boot Starter to make use of the Spring Secu
|
|||
|
||||
By Default, the Spring Security Adapter looks for a `keycloak.json` configuration file. You can make sure it looks at the configuration provided by the Spring Boot Adapter by adding this bean :
|
||||
|
||||
[source]
|
||||
[source,java]
|
||||
----
|
||||
|
||||
@Bean
|
||||
|
|
@ -264,7 +264,7 @@ Spring Boot attempts to eagerly register filter beans with the web application c
|
|||
Therefore, when running the Keycloak Spring Security adapter in a Spring Boot environment, it may be necessary to add two ``FilterRegistrationBean``s to your security configuration to prevent the Keycloak filters from being registered twice.
|
||||
|
||||
|
||||
[source]
|
||||
[source,java]
|
||||
----
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Finally you must specify both a `login-config` and use standard servlet security
|
|||
Here's an example:
|
||||
|
||||
|
||||
[source]
|
||||
[source,xml]
|
||||
----
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ redirected back to the application and remain unauthenticated.
|
|||
|
||||
To enable `login-required` set `onLoad` to `login-required` and pass to the init method:
|
||||
|
||||
[source]
|
||||
[source,javascript]
|
||||
----
|
||||
keycloak.init({ onLoad: 'login-required' })
|
||||
----
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ To configure _mod_auth_openidc_ you'll need
|
|||
|
||||
An example configuration would look like the following.
|
||||
|
||||
[source,xml]
|
||||
[source]
|
||||
----
|
||||
LoadModule auth_openidc_module modules/mod_auth_openidc.so
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ This class can tell you exactly what happened.
|
|||
If this attribute is not set, then the adapter was not responsible for the error code.
|
||||
|
||||
|
||||
[source,javascript]
|
||||
[source,java]
|
||||
----
|
||||
public class SamlAuthenticationError implements AuthenticationError {
|
||||
public static enum Reason {
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ Otherwise this configuration is optional.
|
|||
For example, if you have a JAX-RS service that is an EJB within your WEB-INF/classes directory,
|
||||
you'll want to annotate it with the `@SecurityDomain` annotation as follows:
|
||||
|
||||
[source,xml]
|
||||
[source,java]
|
||||
----
|
||||
|
||||
import org.jboss.ejb3.annotation.SecurityDomain;
|
||||
|
|
|
|||
|
|
@ -74,6 +74,7 @@ A successful response from an exchange invocation will return the HTTP 200 respo
|
|||
depends on the `requested-token-type` and `requested_issuer` the client asks for. OAuth requested token types will return
|
||||
a JSON document as described in the link:https://www.ietf.org/id/draft-ietf-oauth-token-exchange-12.txt[OAuth Token Exchange] specification.
|
||||
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"access_token" : ".....",
|
||||
|
|
@ -90,6 +91,7 @@ Error responses generally fall under the 400 HTTP response code category, but ot
|
|||
depending on the severity of the error. Error responses may include content depending on the `requested_issuer`.
|
||||
OAuth based exchanges may return a JSON document as follows:
|
||||
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"error" : "...."
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ a `org.jboss.logging.Logger` scoped to `ScriptBasedAuthenticator`
|
|||
Note that additional context information can be extracted from the `context` argument passed
|
||||
to the `authenticate(context)` `action(context)` function.
|
||||
|
||||
[source]
|
||||
[source,javascript]
|
||||
----
|
||||
AuthenticationFlowError = Java.type("org.keycloak.authentication.AuthenticationFlowError");
|
||||
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ Applications will need to deserialize the claim it receives from {project_name}
|
|||
Once you deserialize the credential from the access token to the GSSCredential object, the GSSContext will need to be created with this credential
|
||||
passed to the method `GSSManager.createContext` for example like this:
|
||||
|
||||
[source]
|
||||
[source,java]
|
||||
----
|
||||
// Obtain accessToken in your application.
|
||||
KeycloakPrincipal keycloakPrincipal = (KeycloakPrincipal) servletReq.getUserPrincipal();
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ Enable mutual SSL in WildFly::
|
|||
See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-EnableSSL[Enable SSL] and link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-%7B%7B%3Cssl%2F%3E%7D%7D[SSL] for the instructions how to enable SSL in Wildfly.
|
||||
|
||||
* Open {project_dirref}/standalone/configuration/standalone.xml and add a new realm:
|
||||
```
|
||||
```xml
|
||||
<security-realms>
|
||||
<security-realm name="ssl-realm">
|
||||
<server-identities>
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ at the application.
|
|||
|
||||
For example
|
||||
|
||||
[source,java]
|
||||
[source]
|
||||
----
|
||||
GET /myapplication.com?kc_idp_hint=facebook HTTP/1.1
|
||||
Host: localhost:8080
|
||||
|
|
@ -21,7 +21,7 @@ In this case, is expected that your realm has an identity provider with an alias
|
|||
|
||||
If you are using `keycloak.js` adapter, you can also achieve the same behavior:
|
||||
|
||||
[source,java]
|
||||
[source,javascript]
|
||||
----
|
||||
var keycloak = new Keycloak('keycloak.json');
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Application code can retrieve these tokens and responses to pull in extra user i
|
|||
For example, an application might want to use the Google token to invoke on other Google services and REST APIs.
|
||||
To retrieve a token for a particular identity provider you need to send a request as follows:
|
||||
|
||||
[source,java]
|
||||
[source]
|
||||
----
|
||||
GET /auth/realms/{realm}/broker/{provider_alias}/token HTTP/1.1
|
||||
Host: localhost:8080
|
||||
|
|
|
|||
|
|
@ -433,7 +433,7 @@ This jar does not have to be separate from other provider classes but it must co
|
|||
This file must list the fully qualified classname of each RequiredActionFactory implementation you have in the jar.
|
||||
For example:
|
||||
|
||||
[source,java]
|
||||
[source]
|
||||
----
|
||||
org.keycloak.examples.authenticator.SecretQuestionRequiredActionFactory
|
||||
----
|
||||
|
|
@ -704,7 +704,7 @@ This jar must contain a file named `org.keycloak.authentication.FormActionFacto
|
|||
This file must list the fully qualified classname of each FormActionFactory implementation you have in the jar.
|
||||
For example:
|
||||
|
||||
[source,java]
|
||||
[source]
|
||||
----
|
||||
|
||||
org.keycloak.authentication.forms.RegistrationProfile
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ There are some preconditions that must be met by the client application before i
|
|||
|
||||
To initiate the login, the application must fabricate a URL and redirect the user's browser to this URL. The URL looks like this:
|
||||
|
||||
[source,java]
|
||||
[source]
|
||||
----
|
||||
/{auth-server-root}/auth/realms/{realm}/broker/{provider}/link?client_id={id}&redirect_uri={uri}&nonce={nonce}&hash={hash}
|
||||
----
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Application code can retrieve these tokens and responses to pull in extra user i
|
|||
For example, an application might want to use the Google token to invoke on other Google services and REST APIs.
|
||||
To retrieve a token for a particular identity provider you need to send a request as follows:
|
||||
|
||||
[source,java]
|
||||
[source]
|
||||
----
|
||||
GET /auth/realms/{realm}/broker/{provider_alias}/token HTTP/1.1
|
||||
Host: localhost:8080
|
||||
|
|
|
|||
|
|
@ -183,7 +183,7 @@ KEYCLOAK_HOME/bin/jboss-cli.sh --command="module add --name=org.acme.provider --
|
|||
Or to manually create it start by creating the folder `KEYCLOAK_HOME/modules/org/acme/provider/main`.
|
||||
Then copy `provider.jar` to this folder and create `module.xml` with the following content:
|
||||
|
||||
[source]
|
||||
[source,xml]
|
||||
----
|
||||
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
|
|
|
|||
|
|
@ -310,7 +310,7 @@ For example for the `mytheme` theme create `mytheme.zip` with the contents:
|
|||
|
||||
The contents of `META-INF/keycloak-themes.json` in this case would be:
|
||||
|
||||
[source,javascript]
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"themes": [{
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ If you do not specify a path to the proxy config file, the launcher will look in
|
|||
=== Proxy Configuration
|
||||
|
||||
Here's an example configuration file.
|
||||
[source]
|
||||
[source,json]
|
||||
----
|
||||
|
||||
{
|
||||
|
|
@ -231,7 +231,7 @@ KEYCLOAK_ACCESS_TOKEN::
|
|||
Send the access token in this header if the proxy was configured to send it.
|
||||
This token can be used to make bearer token requests. Header field names can be configured using a map of `header-names` in configuration file:
|
||||
+
|
||||
[source]
|
||||
[source,json]
|
||||
----
|
||||
|
||||
{
|
||||
|
|
|
|||
|
|
@ -314,7 +314,7 @@ We added support for offline tokens in this release, which means that we are per
|
|||
If you are not using offline tokens, nothing will be persisted for you, so you don't need to care about worse performance for more DB writes.
|
||||
However in all cases, you will need to update `standalone/configuration/keycloak-server.json` and add `userSessionPersister` like this:
|
||||
|
||||
[source]
|
||||
[source,json]
|
||||
----
|
||||
"userSessionPersister": {
|
||||
"provider": "jpa"
|
||||
|
|
|
|||
|
|
@ -10,6 +10,8 @@ database is automatically migrated when you start the new installation for the f
|
|||
To enable automatic upgrading of the database schema, set the migrationStrategy property value to "update" for the
|
||||
default connectionsJpa provider:
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
<spi name="connectionsJpa">
|
||||
<provider name="default" enabled="true">
|
||||
<properties>
|
||||
|
|
@ -18,6 +20,7 @@ default connectionsJpa provider:
|
|||
</properties>
|
||||
</provider>
|
||||
</spi>
|
||||
----
|
||||
|
||||
Or run this CLI command:
|
||||
|
||||
|
|
@ -34,6 +37,8 @@ in the new version.
|
|||
To enable manual upgrading of the database schema, set the migrationStrategy property value to "manual" for the default
|
||||
connectionsJpa provider:
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
<spi name="connectionsJpa">
|
||||
<provider name="default" enabled="true">
|
||||
<properties>
|
||||
|
|
@ -42,6 +47,7 @@ connectionsJpa provider:
|
|||
</properties>
|
||||
</provider>
|
||||
</spi>
|
||||
----
|
||||
|
||||
Or run this CLI command:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue