libre.sh/keycloak-scim
3
0
Fork 0
Code Issues 15 Pull requests Releases 1 Activity Actions

KEYCLOAK-3823 Docs about pushing not-before will invalidate realm keys

Browse source
This commit is contained in:
mposolda 2016-12-01 17:45:28 +01:00
parent 78efd18cca
commit 82f16098b6
2 changed files with 17 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
topics/realms/keys.adoc
View file

@ -1,4 +1,4 @@
[[_realm_keys]]
=== Realm Keys === Realm Keys
The authentication protocols that are used by {{book.project.name}} require cryptographic signatures and sometimes The authentication protocols that are used by {{book.project.name}} require cryptographic signatures and sometimes
@ -81,3 +81,15 @@ configuration screen for the key provider for the keys. Click on `Enabled` to tu
keys will no longer be active and can only be used for verifying signatures. keys will no longer be active and can only be used for verifying signatures.
Alternatively, you can delete the provider from the `Providers` table. Alternatively, you can delete the provider from the `Providers` table.
==== Compromised keys
{{book.project.name}} has the signing keys stored just locally and they are never shared with the client applications, users or other
entities. However if you think that your realm signing key was compromised, you should first generate new keypair as described above and
then immediatelly remove the compromised keypair.
Then to ensure that client applications won't accept the tokens signed by the compromised key, you should update and push not-before policy for
the realm, which is doable from the admin console. Pushing new policy will ensure that client applications won't accept the existing
tokens signed by the compromised key, but also the client application will be forced to download new keypair from the {{book.project.name}}, hence
the tokens signed by the compromised key won't be valid anymore. Note that your REST and confidential clients must have set `Admin URL`, so that
{{book.project.name}} is able to send them the request about pushed not-before policy.

5
topics/threat/compromised-tokens.adoc
View file

@ -13,6 +13,9 @@ If an admin detects a leak, they can logout all user sessions to invalidate thes
Making sure refresh tokens always stay private to the client and are never transmitted ever is very important as well. Making sure refresh tokens always stay private to the client and are never transmitted ever is very important as well.
If an access token or refresh token is compromised, the first thing you should do is go to the admin console and push a not-before revocation policy to all applications. If an access token or refresh token is compromised, the first thing you should do is go to the admin console and push a not-before revocation policy to all applications.
This will enforce that any tokens issued prior to that date are now invalid. This will enforce that any tokens issued prior to that date are now invalid. Pushing new not-before policy will also ensure that application will be forced to download
new public keys from {{book.project.name}}, hence it is also useful for the case, when you think that realm signing key was compromised.
More info in the <<fake/../../realms/keys.adoc#_realm_keys, keys chapter>>.
You can also disable specific applications, clients, and users if you feel that any one of those entities is completely compromised. You can also disable specific applications, clients, and users if you feel that any one of those entities is completely compromised.