mirror of
https://github.com/keycloak/keycloak.git
synced 2026-01-25 16:42:34 +00:00
Address QE comments on Server Admin Guide
Closes #34916
Signed-off-by: AndyMunro <amunro@redhat.com>
(cherry picked from commit 205898baf3)
This commit is contained in:
committed by
Alexander Schwartz
parent
13833fd221
commit
17863d1d4f
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 13 KiB |
@@ -89,7 +89,7 @@ c:\> kcadm config truststore --trustpass %PASSWORD% %HOMEPATH%\.keycloak\trustst
|
||||
|
||||
=== Sensitive Options
|
||||
|
||||
Sensitive values, such as passwords, may be specified as command options. That is generally not recommended. There are also mechanisms by which you can be prompted for the sensitive value - by either omitting the option or providing a value or -. Finally all will have a corresponding env variable that can be used instead - check the help of the command you are running to see all possible options.
|
||||
Sensitive values, such as passwords, may be specified as command options. That is generally not recommended. There are also mechanisms by which you can be prompted for the sensitive value by either omitting the option or providing a value. Finally all will have a corresponding env variable that can be used instead. Check the help of the command you are running to see all possible options.
|
||||
|
||||
=== Authenticating
|
||||
|
||||
@@ -850,7 +850,7 @@ $ kcadm.sh add-roles -r demorealm --gname Group --cclientid realm-management --r
|
||||
|
||||
Use the `remove-roles` command to remove client roles from a group.
|
||||
|
||||
The following example removes two roles defined on the client `realm management`, `create-client` and `view-users`, from the `Group` group.
|
||||
The following example removes two roles defined on the client `realm-management`, `create-client` and `view-users`, from the `Group` group.
|
||||
|
||||
See <<_group_operations, Group operations>> for more information.
|
||||
[options="nowrap"]
|
||||
@@ -1198,7 +1198,7 @@ $ kcadm.sh remove-roles --uusername testuser --rolename user -r demorealm
|
||||
|
||||
Use an `add-roles` command to add client roles to a user.
|
||||
|
||||
Use the following example to add two roles defined on the client `realm management`, the `create-client` role and the `view-users` role, to the user `testuser`.
|
||||
Use the following example to add two roles defined on the client `realm-management`, the `create-client` role and the `view-users` role, to the user `testuser`.
|
||||
[options="nowrap"]
|
||||
----
|
||||
$ kcadm.sh add-roles -r demorealm --uusername testuser --cclientid realm-management --rolename create-client --rolename view-users
|
||||
@@ -1209,7 +1209,7 @@ $ kcadm.sh add-roles -r demorealm --uusername testuser --cclientid realm-managem
|
||||
|
||||
Use a `remove-roles` command to remove client roles from a user.
|
||||
|
||||
Use the following example to remove two roles defined on the realm management client:
|
||||
Use the following example to remove two roles defined on the realm-management client:
|
||||
[options="nowrap"]
|
||||
----
|
||||
$ kcadm.sh remove-roles -r demorealm --uusername testuser --cclientid realm-management --rolename create-client --rolename view-users
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
[role="_abstract"]
|
||||
Clients are entities that can request authentication of a user. Clients come in two forms.
|
||||
The first type of client is an application that wants
|
||||
to participate in single-sign-on. These clients just want {project_name} to provide security for them. The other type
|
||||
to participate in single sign-on. These clients just want {project_name} to provide security for them. The other type
|
||||
of client is one that is requesting an access token so that it can invoke other services on behalf of the authenticated user.
|
||||
This section discusses various aspects around configuring clients and various ways to do it.
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ The default algorithm is SHA1. The other, more secure options are SHA256 and SHA
|
||||
|
||||
===== Number of digits
|
||||
|
||||
The length of the OTP. Short OTP's are user-friendly, easier to type, and easier to remember. Longer OTP's are more secure than shorter OTP's.
|
||||
The length of the OTP. Short OTPs are user-friendly, easier to type, and easier to remember. Longer OTPs are more secure than shorter OTPs.
|
||||
|
||||
===== Look around window
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ Client Policies realize the following points mentioned as follows.
|
||||
|
||||
Setting policies on what configuration a client can have::
|
||||
Configuration settings on the client can be enforced by client policies during client creation/update, but also during OpenID Connect requests to {project_name} server, which are related to particular client.
|
||||
{project_name} supports similar thing also through the *Client Registration Policies* described in the *Client registration service* from link:{securing_apps_link}[{securing_apps_name}].
|
||||
{project_name} supports similar thing also through the *Client Registration Policies* described in the *Client registration service* in the link:{securing_apps_link}[Securing applications and Services guide].
|
||||
However, Client Registration Policies can only cover OIDC Dynamic Client Registration. Client Policies cover not only what Client Registration Policies can do, but other client
|
||||
registration and configuration ways. The current plans are for Client Registration to be replaced by Client Policies.
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ This choice is the default setting. The secret is automatically generated. Click
|
||||
.Signed JWT
|
||||
image:images/client-credentials-jwt.png[Signed JWT]
|
||||
|
||||
*Signed JWT* is "Signed Json Web Token".
|
||||
*Signed JWT* is "Signed JSON Web Token".
|
||||
|
||||
When choosing this credential type you will have to also generate a private key and certificate for the client in the tab `Keys`. The private key will be used to sign the JWT, while the certificate is used by the server to verify the signature.
|
||||
|
||||
|
||||
@@ -70,6 +70,7 @@ This authenticator sets an existing user to the authentication context without v
|
||||
[NOTE]
|
||||
====
|
||||
This setup is the simplest setup available, but it is possible to use other authenticators. For example:
|
||||
|
||||
* You can add the Review Profile authenticator to the beginning of the flow if you want end users to confirm their profile information.
|
||||
* You can add authentication mechanisms to this flow, forcing a user to verify their credentials. Adding authentication mechanisms requires a complex flow. For example, you can set the "Automatically Set Existing User" and "Password Form" as "Required" in an "Alternative" sub-flow.
|
||||
====
|
||||
|
||||
@@ -51,6 +51,7 @@ Once linked to an organization, the identity provider can be managed just like a
|
||||
== Editing a linked identity provider
|
||||
|
||||
You can edit any of the organization-related settings of a linked identity provider at any time.
|
||||
|
||||
.Procedure
|
||||
|
||||
. In the menu, click *Organizations* and go to the *Identity providers* tab.
|
||||
|
||||
@@ -34,7 +34,7 @@ There are two types of members:
|
||||
|
||||
Managed members are those managed by the organization, and they cannot exist outside of their organization. For instance, consider
|
||||
an account created through an identity provider associated with an organization. That account does not belong to a realm as it was federated from the organization.
|
||||
In this case, the single-source of truth for the identity is the organization and its lifecycle is controlled
|
||||
In this case, the single source of truth for the identity is the organization and its lifecycle is controlled
|
||||
by the organization.
|
||||
If you remove the organization or the member, the account is also removed from the realm.
|
||||
|
||||
|
||||
@@ -64,7 +64,7 @@ protocol mappers::
|
||||
protocol mappers.
|
||||
session::
|
||||
When a user logs in, a session is created to manage the login session. A session contains information like when the user logged in and what
|
||||
applications have participated within single-sign on during that session. Both admins and users can view session information.
|
||||
applications have participated within single sign-on during that session. Both admins and users can view session information.
|
||||
user federation provider::
|
||||
{project_name} can store and manage users. Often, companies already have LDAP or Active Directory services that store user and credential
|
||||
information. You can point {project_name} to validate credentials from those external stores and pull in identity information.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
{project_name} provides the following features:
|
||||
|
||||
* Single-Sign On and Single-Sign Out for browser applications.
|
||||
* Single Sign-On and Single Sign-Out for browser applications.
|
||||
* OpenID Connect support.
|
||||
* OAuth 2.0 support.
|
||||
* SAML support.
|
||||
|
||||
@@ -43,14 +43,13 @@ To add a user to a group:
|
||||
. Click *Users* in the menu.
|
||||
. Click the user that you want to perform a role mapping on. If the user is not displayed, click *View all users*.
|
||||
. Click *Groups*.
|
||||
+
|
||||
.User groups
|
||||
image:images/user-groups.png[]
|
||||
+
|
||||
. Click *Join Group*.
|
||||
. Select a group from the dialog.
|
||||
. Select a group from the *Available Groups* tree.
|
||||
. Click *Join*.
|
||||
+
|
||||
.Join group
|
||||
image:images/user-groups.png[]
|
||||
|
||||
To remove a group from a user:
|
||||
|
||||
|
||||
@@ -147,8 +147,8 @@ The configurable items and their description follow.
|
||||
|
||||
The CIBA grant uses the following two providers.
|
||||
|
||||
. Authentication Channel Provider : provides the communication between {project_name} and the entity that actually authenticates the user via AD (Authentication Device).
|
||||
. User Resolver Provider : get `UserModel` of {project_name} from the information provided by the client to identify the user.
|
||||
. Authentication Channel Provider: provides the communication between {project_name} and the entity that actually authenticates the user via AD (Authentication Device).
|
||||
. User Resolver Provider: get `UserModel` of {project_name} from the information provided by the client to identify the user.
|
||||
|
||||
{project_name} has both default providers. However, the administrator needs to set up Authentication Channel Provider like this:
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ _Redirect_ binding uses a series of browser redirect URIs to exchange informatio
|
||||
|
||||
===== POST binding
|
||||
|
||||
_POST_ binding is similar to _Redirect_ binding but _POST_ binding exchanges XML documents using POST requests instead of using GET requests. _POST_ Binding uses JavaScript to make the browser send a POST request to the {project_name} server or application when exchanging documents. HTTP responds with an HTML document which contains an HTML form containing embedded JavaScript. When the page loads, the JavaScript automatically invokes the form.
|
||||
_POST_ binding is similar to _Redirect_ binding but _POST_ binding exchanges XML documents using POST requests instead of using GET requests. _POST_ binding uses JavaScript to make the browser send a POST request to the {project_name} server or application when exchanging documents. HTTP responds with an HTML document which contains an HTML form containing embedded JavaScript. When the page loads, the JavaScript automatically invokes the form.
|
||||
|
||||
_POST_ binding is recommended due to two restrictions:
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ This is the list of the read-only attributes, which are used internally by the {
|
||||
|
||||
System administrators have a way to add additional attributes to this list. The configuration is currently available at the server level.
|
||||
|
||||
You can add this configuration by using the `spi-user-profile-declarative-user-profile-read-only-attributes` and ``spi-user-profile-declarative-user-profile-admin-read-only-attributes` options. For example:
|
||||
You can add this configuration by using the `spi-user-profile-declarative-user-profile-read-only-attributes` and `spi-user-profile-declarative-user-profile-admin-read-only-attributes` options. For example:
|
||||
|
||||
[source,bash,options="nowrap"]
|
||||
----
|
||||
|
||||
Reference in New Issue
Block a user