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

minor corrections to duplicate text and wording

Browse source
This commit is contained in:
Andy Munro 2021-04-16 17:35:14 -04:00 committed by Marek Posolda
parent c2fdee2d2d
commit a0b31dced3
5 changed files with 5 additions and 34 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
server_admin/topics/realms/keys.adoc
View file

@ -17,14 +17,13 @@ When a realm is created a key pair and a self-signed certificate is automaticall
. Click *Passive* to view passive keys. . Click *Passive* to view passive keys.
. Click *Disabled* to view disabled keys. . Click *Disabled* to view disabled keys.
To view passive or disabled keys select `Passive` or `Disabled`.
A keypair can have the status `Active`, but still not be selected as the currently active keypair for the realm. A keypair can have the status `Active`, but still not be selected as the currently active keypair for the realm.
The selected active pair which is used for signatures is selected based on the first key provider sorted by priority The selected active pair which is used for signatures is selected based on the first key provider sorted by priority
that is able to provide an active keypair. that is able to provide an active keypair.
==== Rotating keys ==== Rotating keys
It's recommended to regularly rotate keys. To do so you should start by creating new keys with a higher priority than We recommend that you regularly rotate keys. To do so, start by creating new keys with a higher priority than
the existing active keys. Or create new keys with the same priority and making the previous keys passive. the existing active keys. Or create new keys with the same priority and making the previous keys passive.
Once new keys are available all new tokens and cookies will be signed with the new keys. When a user authenticates to an Once new keys are available all new tokens and cookies will be signed with the new keys. When a user authenticates to an
@ -32,20 +31,10 @@ application the SSO cookie is updated with the new signature. When OpenID Connec
signed with the new keys. This means that over time all cookies and tokens will use the new keys and after a while the signed with the new keys. This means that over time all cookies and tokens will use the new keys and after a while the
old keys can be removed. old keys can be removed.
How long you wait to delete old keys is a tradeoff between security and making sure all cookies and tokens are updated.
In general it should be acceptable to drop old keys after a few weeks. Users that have not been active in the period
between the new keys where added and the old keys removed will have to re-authenticate.
This also applies to offline tokens. To make sure they are updated the applications need to refresh the tokens before
the old keys are removed.
The frequency of deleting old keys is a tradeoff between security and making sure all cookies and tokens are updated. Consider creating new keys every three to six months and deleting old keys one to two months after you create the new keys. If a user was inactive in the period between the new keys being added and the old keys being removed, that user will have to re-authenticate. The frequency of deleting old keys is a tradeoff between security and making sure all cookies and tokens are updated. Consider creating new keys every three to six months and deleting old keys one to two months after you create the new keys. If a user was inactive in the period between the new keys being added and the old keys being removed, that user will have to re-authenticate.
Rotating keys also applies to offline tokens. To make sure they are updated, the applications need to refresh the tokens before the old keys are removed. Rotating keys also applies to offline tokens. To make sure they are updated, the applications need to refresh the tokens before the old keys are removed.
As a guideline, it may be a good idea to create new keys every 3-6 months and delete old keys 1-2 months after the new
keys were created.
==== Adding a generated keypair ==== Adding a generated keypair
.Procedure .Procedure
@ -58,7 +47,7 @@ keys were created.
. Select a value for *keysize*. . Select a value for *keysize*.
. Click *Save*. . Click *Save*.
Click `Save` to add the new keys. This will generated a new keypair including a self-signed certificate. This action will generated a new keypair including a self-signed certificate.
Changing the priority for a provider will not cause the keys to be re-generated, but if you want to change the keysize Changing the priority for a provider will not cause the keys to be re-generated, but if you want to change the keysize
you can edit the provider and new keys will be generated. you can edit the provider and new keys will be generated.

2
server_admin/topics/realms/master.adoc
View file

@ -7,7 +7,7 @@ In the Admin Console, two types of realms exist:
* `Other realms` - These realms are created by the administrator in the master realm. In these realms, administrators manage the users in your organization and the applications they need. The applications are owned by the users. * `Other realms` - These realms are created by the administrator in the master realm. In these realms, administrators manage the users in your organization and the applications they need. The applications are owned by the users.
.Realms and applications .Realms and applications
image:getting_started/images/master_realm.png[Realms and applications] image:../../../getting_started/images/master_realm.png[Realms and applications]
Realms are isolated from one another and can only manage and authenticate the users that they control. Following this security model helps prevent accidental changes and follows the tradition Realms are isolated from one another and can only manage and authenticate the users that they control. Following this security model helps prevent accidental changes and follows the tradition
of permitting user accounts access to only those privileges and powers necessary of permitting user accounts access to only those privileges and powers necessary

18
server_admin/topics/roles-groups.adoc
View file

@ -1,18 +0,0 @@
== Assigning permissions and access using roles and groups
Roles and groups have a similar purpose, which is to give users access and permissions to use applications. Groups are a collection of users to which you apply roles and attributes. Roles define specific applications permissions and access control. Groups are an optional capability.
A role typically applies to one type of user. Typical roles in an organization include `Admin`, `user`, `manager`, and `employee`. An application can assign access and permissions to a role and then assign multiple users to that role so the users share the same access and permissions. For example, the Admin Console has roles that give permission to users to access parts of the Admin Console.
There is a global namespace for roles and each client also has its own dedicated namespace where roles can be defined.
include::roles-groups/proc-creating-realm-roles.adoc[]
include::roles-groups/con-client-roles.adoc[]
include::roles-groups/proc-converting-composite-roles.adoc[]
include::roles-groups/proc-assigning-role-mappings.adoc[]
include::roles-groups/con-default-roles.adoc[]
include::roles-groups/con-role-scope-mappings.adoc[]
include::roles-groups/proc-managing-groups.adoc[]
include::roles-groups/con-comparing-groups-roles.adoc[]
include::roles-groups/proc-specifying-default-groups.adoc[]

2
server_admin/topics/sessions/offline.adoc
View file

@ -14,7 +14,7 @@ If you enable <<_offline-session-max-limited, Offline Session Max Limited>>, off
If you enable the <<_revoke-refresh-token, Revoke Refresh Token>> option, you can use each offline token once only. After refresh, you must store the new offline token from the refresh response instead of the previous one. If you enable the <<_revoke-refresh-token, Revoke Refresh Token>> option, you can use each offline token once only. After refresh, you must store the new offline token from the refresh response instead of the previous one.
Users can view and revoke offline tokens that {project_name} grants them in the <<_account-service, User Account Service>>. Administrators can revoke offline tokens for individual users in the Admin Console in the `Consents` tab. Administrators can view all offline tokens issued in the `Offline Access` tab of each client. Administrators can revoke offline tokens by setting a <<_revocation-policy, revocation policy>>. Users can view and revoke offline tokens that {project_name} grants them in the <<_account-service, User Account Console>>. Administrators can revoke offline tokens for individual users in the Admin Console in the `Consents` tab. Administrators can view all offline tokens issued in the `Offline Access` tab of each client. Administrators can revoke offline tokens by setting a <<_revocation-policy, revocation policy>>.
To issue an offline token, users must have the role mapping for the realm-level `offline_access` role. Clients must also have that role in their scope. Clients must add an `offline_access` client scope as an `Optional client scope` to the role, which is done by default. To issue an offline token, users must have the role mapping for the realm-level `offline_access` role. Clients must also have that role in their scope. Clients must add an `offline_access` client scope as an `Optional client scope` to the role, which is done by default.