fixed RHSSO-876
This commit is contained in:
parent
1e093d822e
commit
2e00b7cf6d
3 changed files with 10 additions and 20 deletions
|
@ -2,12 +2,9 @@
|
|||
|
||||
== Export and Import
|
||||
|
||||
{{book.project.name}} has the ability export and import the entire database.
|
||||
This can be especially useful if you want to migrate your whole {{book.project.name}} database from one environment to another
|
||||
or migrate to a different database (for example from MySQL to Oracle). Export and import
|
||||
is triggered at server boot time and its parameters are passed in via Java system properties.
|
||||
It is important to note that because import and export happens at server startup, no other actions should be taken on the server
|
||||
or the database while this happens.
|
||||
{{book.project.name}} has the ability to export and import the entire database.
|
||||
This can be especially useful if you want to migrate your whole {{book.project.name}} database from one environment to another or migrate to a different database (for example from MySQL to Oracle). Export and import is triggered at server boot time and its parameters are passed in via Java system properties.
|
||||
It is important to note that because import and export happens at server startup, no other actions should be taken on the server or the database while this happens.
|
||||
|
||||
You can export/import your database either to:
|
||||
|
||||
|
@ -100,3 +97,4 @@ Note: The admin console import allows just one realm per file.
|
|||
|
||||
WARNING: The admin console import allows you to "overwrite" resources if you choose.
|
||||
Use this feature with caution, especially on a production system.
|
||||
|
||||
|
|
|
@ -1,20 +1,12 @@
|
|||
|
||||
=== Compromised Access and Refresh tokens
|
||||
=== Compromised Access and Refresh Tokens
|
||||
|
||||
There are a few things you can do to mitigate access tokens and refresh tokens from being stolen.
|
||||
The most important thing is to enforce SSL/HTTPS communication between {{book.project.name}} and its clients and applications.
|
||||
This might seem like a no-brainer, but since {{book.project.name}} does not have SSL enabled by default, many naive admins
|
||||
might not realize they have to do this.
|
||||
There are a few things you can do to mitigate access tokens and refresh tokens from being stolen. The most important thing is to enforce SSL/HTTPS communication between {{book.project.name}} and its clients and applications. It might seem obvious, but since {{book.project.name}} does not have SSL enabled by default, an adminstrator might not realize that it is necessary.
|
||||
|
||||
Another thing you can do to mitigate leaked access tokens is to shorten their lifespans. You can specify this
|
||||
within the <<fake/../../sessions/timeouts.adoc#_timeouts, timeouts page>>.
|
||||
Short lifespans (minutes) for access tokens for clients and applications to refresh their access tokens after a short amount of time.
|
||||
If an admin detects a leak, they can logout all user sessions to invalidate these refresh tokens or set up a revocation policy.
|
||||
Making sure refresh tokens always stay private to the client and are never transmitted ever is very important as well.
|
||||
Another thing you can do to mitigate leaked access tokens is to shorten their lifespans. You can specify this within the <<fake/../../sessions/timeouts.adoc#_timeouts, timeouts page>>.
|
||||
Short lifespans (minutes) for access tokens for clients and applications to refresh their access tokens after a short amount of time. If an admin detects a leak, they can logout all user sessions to invalidate these refresh tokens or set up a revocation policy. 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.
|
||||
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.
|
||||
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. 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.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
=== SSL/HTTPS Requirement
|
||||
|
||||
If you do not use SSL/HTTPS for all communication between the {{book.project.name}} auth server and the clients it secures you will be very vulnerable to man in the middle attacks.
|
||||
If you do not use SSL/HTTPS for all communication between the {{book.project.name}} auth server and the clients it secures, you will be very vulnerable to man in the middle attacks.
|
||||
OAuth 2.0/OpenID Connect uses access tokens for security.
|
||||
Without SSL/HTTPS, attackers can sniff your network and obtain an access token.
|
||||
Once they have an access token they can do any operation that the token has been given permission for.
|
||||
|
|
Loading…
Reference in a new issue