KEYCLOAK-17491 Move the key settings to the new Keys tab

This commit is contained in:
Yoshiyuki Tabata 2021-03-22 14:28:52 +09:00 committed by Marek Posolda
parent cd3950684f
commit fde7cdeb70
20 changed files with 11 additions and 8 deletions

View file

@ -28,7 +28,7 @@ This is based on the https://tools.ietf.org/html/rfc7523[RFC7523] specification.
the particular backchannel request (for example, code-to-token request) in the `client_assertion` parameter.
* {project_name} must have the public key or certificate of the client so that it can verify the signature on JWT. In {project_name} you need to configure client credentials for your client. First you need to choose `Signed JWT` as the method of authenticating your client in the tab `Credentials` in administration console.
Then you can choose to either:
Then you can choose to either in the tab `Keys`:
** Configure the JWKS URL where {project_name} can download the client's public keys. This can be a URL such as \http://myhost.com/myapp/k_jwks (see details above). This option is the most flexible, since the client can rotate its keys anytime and {project_name} then always downloads new keys when needed without needing to change the configuration. More accurately, {project_name} downloads new keys when it sees the token signed by an unknown `kid` (Key ID).
** Upload the client's public key or certificate, either in PEM format, in JWK format, or from the keystore. With this option, the public key is hardcoded and must be changed when the client generates a new key pair.
You can even generate your own keystore from the {project_name} admininstration console if you don't have your own available.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 52 KiB

After

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 45 KiB

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 50 KiB

After

Width:  |  Height:  |  Size: 43 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 152 KiB

After

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 68 KiB

After

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 60 KiB

After

Width:  |  Height:  |  Size: 50 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 53 KiB

After

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 33 KiB

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 57 KiB

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 48 KiB

After

Width:  |  Height:  |  Size: 34 KiB

View file

@ -184,9 +184,8 @@ In Key Encryption, the client generates a key pair of asymmetric cryptography. T
The client needs to pass their public key for encrypting CEK onto {project_name}. {project_name} supports downloading public keys from the URL the client provides. The client needs to provide their public keys according to https://tools.ietf.org/html/rfc7517[Json Web Keys (JWK)] specification. The way to do so is defined in `Signed JWT` of <<_client-credentials, Confidential Client Credentials>>. The detailed procedure is as follows:
* open the client's `Credentials` tab
* select `Signed Jwt` from `Client Authenticator` pulldown menu
* set ON to `JWKS URL` switch
* open the client's `Keys` tab
* toggle `JWKS URL` to ON
* input the client's public key providing URL on `JWKS URL` textbox
Key Encryption's algorithms are defined in the https://tools.ietf.org/html/rfc7518#section-4.1[Json Web Algorithm (JWA)] specification. {project_name} supports RSAES-PKCS1-v1_5(RSA1_5), RSAES OAEP using default parameters (RSA-OAEP), and RSAES OAEP 256 using SHA-256 and MFG1 (RSA-OAEP-256). The detailed procedure to select this algorithm is as follows:

View file

@ -98,7 +98,7 @@ Encrypt Assertions::
Client Signature Required::
Expect that documents coming from a client are signed.
{project_name} will validate this signature using the client public key or cert set up in the `SAML Keys` tab.
{project_name} will validate this signature using the client public key or cert set up in the `Keys` tab.
Force POST Binding::
By default, {project_name} will respond using the initial SAML binding of the original request.

View file

@ -20,9 +20,13 @@ Alternatively, you can opt to use a signed Json Web Token (JWT) or x509 certific
.Signed JWT
image:{project_images}/client-credentials-jwt.png[]
When choosing this credential type you will have to also generate a private key and certificate for the client. The private key
will be used to sign the JWT, while the certificate is used by the server to verify the signature. Click on the
`Generate new keys and certificate` button to start this process.
When choosing this credential type you will have to also generate a private key and certificate for the client in the tab `Keys`.
The private key will be used to sign the JWT, while the certificate is used by the server to verify the signature.
.Keys Tab
image:{project_images}/client-oidc-keys.png[]
Click on the `Generate new keys and certificate` button to start this process.
.Generate Keys
image:{project_images}/generate-client-keys.png[]