fixed RHSSO-876

This commit is contained in:
Jen Malloy 2017-03-15 13:35:07 -04:00
parent 1e093d822e
commit 2e00b7cf6d
3 changed files with 10 additions and 20 deletions

View file

@ -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.

View file

@ -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.

View file

@ -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.