libre.sh/keycloak-scim
2
0
Fork 0
Code Issues 14 Pull requests Releases Packages Activity Actions 6

Merge pull request #50 from jenmalloy/RHSSO-890

Browse source 
fixed RHSSO-890
This commit is contained in:
Jen Malloy 2017-03-15 14:42:59 -04:00 committed by GitHub
commit ff0589ed0a
2 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
server_admin/topics/admin-cli.adoc
View file

@ -115,7 +115,7 @@ See `kcadm.sh config credentials --help` for more information about starting an
By default, `Admin CLI` automatically maintains a configuration file at a default location - `.keycloak/kcadm.config`
under user's home directory.
You can use `--config` option at any time to point to a different file / location. This way you can mantain multiple authenticated
You can use `--config` option at any time to point to a different file / location. This way you can maintain multiple authenticated
sessions in parallel. It is safest to perform operations tied to a single config file from a single thread.
Make sure to not make a config file visible to other users on the system as it contains access tokens, and secrets that should be kept private.
@ -256,7 +256,7 @@ It's very simple to delete a realm:
Turning on all login page options for the realm::
Set the attributes controlling specific capabilites to `true`.
Set the attributes controlling specific capabilities to `true`.
For example:
@ -663,7 +663,7 @@ Use `delete` operation with the same endpoint uri as for getting a specific clie
Creating a user::
A new user can be created using `create` command agains `users` endpoint. For example:
A new user can be created using the `create` command against the `users` endpoint. For example:
$ kcadm.sh create users -r demorealm -s username=testuser -s enabled=true

2
server_admin/topics/threat/compromised-tokens.adoc
View file

@ -1,7 +1,7 @@
=== 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. 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.
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 administrator 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.