Fix minor typos in the 'Server Administration' guide (#1703)

server_admin/topics/License.adoc

@@ -7,5 +7,5 @@
 :sourcedir: .
 
 Keycloak codebase is distributed under the ASL 2.0 license.
-It does not distribute any thirdparty libraries that are GPL.
-It does ship thirdparty libraries licensed under Apache ASL 2.0 and LGPL. 
+It does not distribute any third party libraries that are GPL.
+It does ship third party libraries licensed under Apache ASL 2.0 and LGPL.

server_admin/topics/admin-cli.adoc

@@ -1494,7 +1494,7 @@ $ kcadm.sh create identity-provider/instances -r demorealm -s alias=saml -s prov
 ==== Configuring a Facebook identity provider
 
 . Use `facebook` as the `providerId`.
-. Provide the `config` attributes: `clientId` and `clientSecret`. You can find these attributes in the Facebook Developers application configuration page for your application. See see the <<_facebook, facebook identity broker>> page for more information.
+. Provide the `config` attributes: `clientId` and `clientSecret`. You can find these attributes in the Facebook Developers application configuration page for your application. See the <<_facebook, Facebook identity broker>> page for more information.
 +
 For example:
 +
@@ -1533,7 +1533,7 @@ $ kcadm.sh create identity-provider/instances -r demorealm -s alias=google -s pr
 ==== Configuring a GitHub identity provider
 
 . Use `github` as the `providerId`.
-. Provide the `config` attributes `clientId` and `clientSecret`. You can find these attributes in the GitHub Developer Application Settings page for your application. See the <<_github, Github identity broker>> page for more information.
+. Provide the `config` attributes `clientId` and `clientSecret`. You can find these attributes in the GitHub Developer Application Settings page for your application. See the <<_github, GitHub identity broker>> page for more information.
 +
 For example:
 +

server_admin/topics/admin-console-permissions/fine-grain.adoc

@@ -26,7 +26,7 @@ There are some important things to note about fine grain admin permissions:
 * Fine grain admin permissions were implemented on top of link:{authorizationguide_link}[Authorization Services].  It is highly recommended that you read up on those features before diving into fine grain permissions.
 * Fine grain permissions are only available within <<_per_realm_admin_permissions, dedicated admin consoles>> and admins defined within those realms.  You cannot define cross-realm fine grain permissions.
 * Fine grain permissions are used to grant additional permissions.  You cannot override the
-  default behavior of the built in admin roles.
+  default behavior of the built-in admin roles.
 
 ==== Managing one specific client
 

server_admin/topics/admin-console-permissions/master-realm.adoc

@@ -5,7 +5,7 @@ The `master` realm in {project_name} is a special realm and treated differently
 Users in the {project_name} `master` realm can be granted permission to manage zero or more realms that are deployed on the {project_name} server.
 When a realm is created, {project_name} automatically creates various roles that grant fine-grain permissions to access that new realm.
 Access to The Admin Console and Admin REST endpoints can be controlled by mapping these roles to users in the `master` realm.
-It's possible to create multiple super users,  as well as users that can only manage specific realms.
+It's possible to create multiple superusers,  as well as users that can only manage specific realms.
 
 ==== Global roles
 
@@ -15,7 +15,7 @@ These are:
 * admin
 * create-realm        
 
-Users with the `admin` role are super users and have full access to manage any realm on the server.  Users with the `create-realm` role
+Users with the `admin` role are superusers and have full access to manage any realm on the server.  Users with the `create-realm` role
 are allowed to create new realms.  They will be granted full access to any new realm they create.
 
 ==== Realm specific roles

server_admin/topics/authentication/conditions.adoc

@@ -62,7 +62,7 @@ Describes a name of the execution, which will be shown in the authentication flo
 Error message:::
 Error message which will be shown to the user.
 The error message could be provided as a particular message or as a property in order to use it with localization.
-(i.e "_You do not have the role 'admin'._", _my-property-deny_ in messages properties)
+(i.e. "_You do not have the role 'admin'._", _my-property-deny_ in messages properties)
 Leave blank for the default message defined as property `access-denied`.
 
 Here is an example how to deny access to all users who do not have the role `role1` and show an error message defined by a property `deny-role1`.

server_admin/topics/authentication/flows.adoc

@@ -134,7 +134,7 @@ Make sure to properly test your configuration when you configure the authenticat
 corner cases. For example, consider testing the authentication behavior for a user when you remove various credentials from the user's account before authentication.
 
 As an example, when 2nd-factor authenticators, such as OTP Form or WebAuthn Authenticator, are configured in the flow as REQUIRED and the user does not have credential of particular
-type, the user will be able to setup the particular credential during authentication itself. This situation means that the user does not authenticate with this credential as he setup
+type, the user will be able to set up the particular credential during authentication itself. This situation means that the user does not authenticate with this credential as he set up
 it right during the authentication. So for browser authentication, make sure to configure your authentication flow with some 1st-factor credentials such as Password or WebAuthn
 Passwordless Authenticator.
 ====
@@ -203,7 +203,7 @@ At this stage, the form requires a username but no password. We must enable pass
 
 Finally, change the bindings.
 
-. Click the *Action* menu on the top of the screen.
+. Click the *Action* menu at the top of the screen.
 . Select *Bind flow* from the menu.
 . Click the *Browser Flow* drop-down list.
 . Click *Save*.
@@ -224,7 +224,7 @@ Since the WebAuthn Passwordless execution is set to *Alternative* rather than  *
 . Enabling the *Webauthn Register Passwordless* required action in the realm (see the xref:webauthn_{context}[WebAuthn] documentation).
 . Setting the required action using the *Credential Reset* part of a user's xref:ref-user-credentials_{context}[Credentials] management menu.
 
-Creating an advanced flow such as this can have side effects. For example, if you enable the ability to reset the password for users, this would be accessible from the password form. In the default `Reset Credentials` flow, users must enter their username. Since the user has already entered a username earlier in the `Browser Password-less` flow, this action is unnecessary for {project_name} and sub-optimal for user experience. To correct this problem, you can:
+Creating an advanced flow such as this can have side effects. For example, if you enable the ability to reset the password for users, this would be accessible from the password form. In the default `Reset Credentials` flow, users must enter their username. Since the user has already entered a username earlier in the `Browser Password-less` flow, this action is unnecessary for {project_name} and suboptimal for user experience. To correct this problem, you can:
 
 * Duplicate the `Reset Credentials` flow. Set its name to `Reset Credentials for password-less`, for example.
 * Click *Delete* (trash icon) of the *Choose user* step.
@@ -310,7 +310,7 @@ image:images/authentication-step-up-condition-2.png[Autehtnication step up condi
 
 Finally, change the bindings.
 
-. Click the *Action* menu on the top of the screen.
+. Click the *Action* menu at the top of the screen.
 . Select *Bind flow* from the list.
 . Select *Browser Flow* in the dropdown.
 . Click *Save*.
@@ -359,7 +359,7 @@ The logic for the previous configured authentication flow is as follows: +
 If a client request a high authentication level, meaning Level of Authentication 2 (LoA 2), a user has to perform full 2-factor authentication: Username/Password + OTP.
 However, if a user already has a session in Keycloak, that was logged in with username and password (LoA 1), the user is only asked for the second authentication factor (OTP).
 
-The option *Max Age* in the condition determines how long (how much seconds) the subsequent authentication level is valid. This settings helps to decide
+The option *Max Age* in the condition determines how long (how much seconds) the subsequent authentication level is valid. This setting helps to decide
 whether the user will be asked to present the authentication factor again during a subsequent authentication. If the particular level X is requested
 by the `claims` or `acr_values` parameter and user already authenticated with level X, but it is expired (for example max age is configured to 300 and user authenticated before 310 seconds)
 then the user will be asked to re-authenticate again with the particular level. However if the level is not yet expired, the user will be automatically
@@ -371,7 +371,7 @@ with the specific level.
 
 WARNING: Note that parameters such as `claims` or `acr_values` might be changed by the user in the URL when the login request is sent from the client to the {project_name} via the user's browser.
 This situation can be mitigated if client uses PAR (Pushed authorization request), a request object, or other mechanisms that prevents the user from rewrite the parameters in the URL.
-Hence after the authentication, clients are encouraged to check the ID Token to doublecheck that `acr` in the token corresponds to the expected level.
+Hence after the authentication, clients are encouraged to check the ID Token to double-check that `acr` in the token corresponds to the expected level.
 
 If no explicit level is requested by parameters, the {project_name} will require the authentication with the first LoA
 condition found in the authentication flow, such as the Username/Password in the preceding example. When a user was already authenticated with that level
@@ -425,7 +425,7 @@ If both session limits and client session limits are enabled, it makes sense to
 
 Note that the user session limits should be added to your bound *Browser flow*, *Direct grant flow*, *Reset credentials* and also to any *Post broker login flow*.
 The authenticator should be added at the point when the user is already known during authentication (usually at the end of the authentication flow) and should be typically REQUIRED. Note that it is not possible to have
-ALTERNATIVE and REQUIRED executions at the same level. For example for the default browser flow, it may be necessary to wrap the existing flow as a REQUIRED level-1 subflow and 
+ALTERNATIVE and REQUIRED executions at the same level. For example for the default browser flow, it may be necessary to wrap the existing flow as a REQUIRED level-1 subflow and
 add `User Session Count Limiter` to the same level as this new subflow. Example of such flow is below.
 
 image:images/authentication-user-session-limits.png[Authentication User Session Limits Flow]

server_admin/topics/authentication/kerberos.adoc

@@ -83,7 +83,7 @@ image:images/browser-flow.png[Browser Flow]
 
 Set the *Kerberos* requirement from _disabled_ to _alternative_ (Kerberos is optional) or _required_ (browser must have Kerberos enabled). If you have not configured the browser to work with SPNEGO or Kerberos, {project_name} falls back to the regular login screen.
 
-===== Configure Kerberos user storage federation providerxs
+===== Configure Kerberos user storage federation providers
 
 You must now use <<_user-storage-federation,User Storage Federation>> to configure how {project_name} interprets Kerberos tickets. Two different federation providers exist with Kerberos authentication support.
 

server_admin/topics/authentication/webauthn.adoc

@@ -43,7 +43,7 @@ If you require WebAuthn for all users:
 +
 image:images/webauthn-browser-flow-required.png[Webauthn browser flow required]
 +
-. Click the *Action* menu on the top of the screen.
+. Click the *Action* menu at the top of the screen.
 . Select *Bind flow* from the drop-down list.
 . Select *Browser* from the drop-down list.
 . Click *Save*.
@@ -67,7 +67,7 @@ Users can log in with WebAuthn if they have a WebAuthn credential registered onl
 . Click *Add*.
 . Select *Required* for the *Condition - User Configured* to set its requirement to required.
 . Drag and drop *WebAuthn Authenticator* into the *Conditional 2FA* flow
-. Select *Alternative* for the *WebAuthn Authenticator* to set its requirement to alernative.
+. Select *Alternative* for the *WebAuthn Authenticator* to set its requirement to alternative.
 +
 image:images/webauthn-browser-flow-conditional.png[Webauthn browser flow conditional]
 
@@ -78,7 +78,7 @@ The user can choose between using WebAuthn and OTP for the second factor:
 . Click *Add step*.
 . Select *OTP Form* from the list.
 . Click *Add*.
-. Select *Alternative* for the *OTP Form* to set its requirement to alernative.
+. Select *Alternative* for the *OTP Form* to set its requirement to alternative.
 +
 image:images/webauthn-browser-flow-conditional-with-OTP.png[WebAuthn browser flow conditional with OTP]
 
@@ -266,7 +266,7 @@ To use Windows Hello based credentials to authenticate against {project_name}, c
 [[_webauthn-supported-keys]]
 ====== Supported security keys
 
-The following security keys have been successfuly tested for loginless authentication with {project_name}:
+The following security keys have been successfully tested for loginless authentication with {project_name}:
 
 * Windows Hello (Windows 10 21H1/21H2)
 * Yubico Yubikey 5 NFC

server_admin/topics/clients/client-policies.adoc

@@ -22,10 +22,10 @@ Setting policies on what configuration a client can have::
 
 Validation of client configurations::
     {project_name} supports validation whether the client follows settings like Proof Key for Code Exchange,
-    Request Object Signing Algorithm, Holder-of-Key Token, and so on on some endpoints like Authorization Endpoint, Token Endpoint, and so on.
-    These can be specified by each setting item (on Admin Console, switch, pulldown menu and so on). To make the client application secure, the administrator needs to set
+    Request Object Signing Algorithm, Holder-of-Key Token, and so on some endpoints like Authorization Endpoint, Token Endpoint, and so on.
+    These can be specified by each setting item (on Admin Console, switch, pull-down menu and so on). To make the client application secure, the administrator needs to set
     many settings in the appropriate way, which makes it difficult for the administrator to secure the client application.
-    Client Policies can do these validation of client configurations mentioned just above and they can also be used to auto-configure some client configuration switches to meet
+    Client Policies can do these validation of client configurations mentioned just above and they can also be used to autoconfigure some client configuration switches to meet
     the advanced security requirements. In the future, individual client configuration settings may be replaced by Client Policies directly performing required validations.
 
 Conformance to a required security standards and profiles such as FAPI::
@@ -107,7 +107,7 @@ on the OIDC authorization request). Events are:
 * Sending a userinfo request
 * Sending a logout request with a refresh token
 
-On each event, an executor can work in multiple phases. For example, on creating/updating a client, the executor can modify the client configuration by auto-configure specific client
+On each event, an executor can work in multiple phases. For example, on creating/updating a client, the executor can modify the client configuration by autoconfigure specific client
 settings. After that, the executor validates this configuration in validation phase.
 
 One of several purposes for this executor is to realize the security requirements of client conformance profiles like FAPI. To do so, the following executors are needed:
@@ -158,4 +158,4 @@ The current plans are for the Client Registration Policies feature to be removed
 
 == Client Secret Rotation Example
 
-See an example configuration for <<_proc-secret-rotation,client secret rotation>>.
+See an example configuration for <<_proc-secret-rotation,client secret rotation>>.

server_admin/topics/clients/con-protocol-mappers.adoc

@@ -20,7 +20,7 @@ image:images/mappers-oidc.png[]
 New clients do not have built-in mappers but they can inherit some mappers from client scopes. See the <<_client_scopes, client scopes section>> for more details. 
 
 Protocol mappers map items (such as an email address, for example) to
-a specific claim in the identity and access token. The function of a mapper should be self explanatory from its name. You  add pre-configured mappers by clicking *Add Builtin*.
+a specific claim in the identity and access token. The function of a mapper should be self-explanatory from its name. You  add pre-configured mappers by clicking *Add Builtin*.
 
 Each mapper has a set of common settings. Additional settings are available, depending on the mapper type. Click *Edit* next to a mapper to access the configuration screen to adjust these settings.
 

server_admin/topics/clients/oidc/con-advanced-settings.adoc

@@ -107,7 +107,6 @@ An administrator can select one of these options:
 
 See https://datatracker.ietf.org/doc/html/rfc7636[RFC 7636 Proof Key for Code Exchange by OAuth Public Clients] for more details.
 
-
 [[_mapping-acr-to-loa-client]]
 *ACR to Level of Authentication (LoA) Mapping*
 
@@ -121,7 +120,7 @@ a `claims` parameter that has an `acr` claim attached. See https://openid.net/sp
 WARNING: Note that default ACR values are used as the default level, however it cannot be reliably used to enforce login with the particular level.
 For example, assume that you configure the `Default ACR Values` to level 2. Then by default, users will be required to authenticate with level 2.
 However when the user explicitly attaches the parameter into login request such as `acr_values=1`, then the level 1 will be used. As a result, if the client
-really requires level 2, the client is encouraged to check the presence of the `acr` claim inside ID Token and doublecheck that it contains the requested level 2.
+really requires level 2, the client is encouraged to check the presence of the `acr` claim inside ID Token and double-check that it contains the requested level 2.
 
 image:images/client-oidc-map-acr-to-loa.png[alt="ACR to LoA mapping"]
 

server_admin/topics/clients/oidc/con-audience.adoc

@@ -88,7 +88,7 @@ If you need the client itself as an audience, see the
 When your service relies on realm roles or does not rely on the roles in the token at all, it can be useful to use a hardcoded audience. A hardcoded audience is a protocol mapper, that will add the client ID of the specified service client as an audience to the token.
 You can use any custom value, for example a URL, if you want to use a different audience than the client ID.
 
-You can add the protocol mapper directly to the frontend client. If the protocol mapper is added directly, the audience will be always added as well.
+You can add the protocol mapper directly to the frontend client. If the protocol mapper is added directly, the audience will always be added as well.
 
 For more control over the protocol mapper, you can create the protocol mapper on the dedicated client scope, which will be called for example *good-service*.
 

server_admin/topics/clients/oidc/con-basic-settings.adoc

@@ -9,7 +9,7 @@ image:images/client-settings-oidc.png[Settings tab]
 
 == General Settings
 
-*Client ID*:: The alpha-numeric ID string that is used in OIDC requests and in the {project_name} database to identify the client.
+*Client ID*:: The alphanumeric ID string that is used in OIDC requests and in the {project_name} database to identify the client.
 
 *Name*:: The name for the client in {project_name} UI screen. To localize
 the name, set up a replacement string value. For example, a string value such as $\{myapp}.  See the link:{developerguide_link}[{developerguide_name}] for more information.
@@ -96,6 +96,6 @@ There will be also one item on the consent screen about this client itself.
 *Backchannel logout URL*:: URL that will cause the client to log itself out when a logout request is sent to this realm (via end_session_endpoint). If omitted, no logout requests are sent to the client.
 
 *Backchannel logout session required*::
-Specifyies whether a session ID Claim is included in the Logout Token when the *Backchannel Logout URL* is used.
+Specifies whether a session ID Claim is included in the Logout Token when the *Backchannel Logout URL* is used.
 
 *Backchannel logout revoke offline sessions*:: Specifies whether a revoke_offline_access event is included in the Logout Token when the Backchannel Logout URL is used. {project_name} will revoke offline sessions when receiving a Logout Token with this event.

server_admin/topics/clients/oidc/proc-creating-oidc-client.adoc

@@ -14,7 +14,7 @@ image:images/add-client-oidc.png[Create Client]
 . Leave *Client type* set to *OpenID Connect*.
 . Enter a *Client ID.*
 +
-This ID is an alpha-numeric string that is used in OIDC requests and in the {project_name} database to identify the client.
+This ID is an alphanumeric string that is used in OIDC requests and in the {project_name} database to identify the client.
 . Supply a *Name* for the client.
 +
 If you plan to localize this name, set up a replacement string value. For example, a string value such as $\{myapp}.  See the link:{developerguide_link}[{developerguide_name}] for more information.

server_admin/topics/clients/oidc/proc-using-a-service-account.adoc

@@ -61,7 +61,7 @@ Pragma: no-cache
 ----
 
 Only the access token is returned by default. No refresh token is returned and no user session is created
-on the {project_name} side upon successful authentication by default. Due to the lack of refresh token, re-authentication is required when the access token expires. However, this situation does not mean any additional overhead for the {project_name} server because sessions are not created by default.
+on the {project_name} side upon successful authentication by default. Due to the lack of a refresh token, re-authentication is required when the access token expires. However, this situation does not mean any additional overhead for the {project_name} server because sessions are not created by default.
 
 In this situation, logout is unnecessary. However, issued access tokens can be revoked by sending requests to the OAuth2 Revocation Endpoint as described in the xref:con-oidc_{context}[OpenID Connect Endpoints] section.
 

server_admin/topics/clients/oidc/service-accounts.adoc

@@ -50,7 +50,7 @@ Pragma: no-cache
 ----
 
 There is the only access token returned by default. There is no refresh token returned and there is also no user session created
-on the {project_name} side upon successful authentication by default. Due the lack of refresh token, there is a need to re-authenticate when access token expires,
+on the {project_name} side upon successful authentication by default. Due to the lack of a refresh token, there is a need to re-authenticate when access token expires,
 however this does not mean any additional overhead on  {project_name} server side due the fact that sessions are not created by default.
 
 Due to this, there is no need for logout, however issued access tokens can be revoked by sending request to the OAuth2 Revocation Endpoint described

server_admin/topics/clients/saml/proc-creating-saml-client.adoc

@@ -28,7 +28,7 @@ image:images/client-settings-saml.png[]
 
 === General settings
 
-*Client ID*:: The alpha-numeric ID string that is used in OIDC requests and in the {project_name} database to identify the client. This value must match the issuer value sent with AuthNRequests. {project_name} pulls the issuer from the Authn SAML request and match it to a client by this value.
+*Client ID*:: The alphanumeric ID string that is used in OIDC requests and in the {project_name} database to identify the client. This value must match the issuer value sent with AuthNRequests. {project_name} pulls the issuer from the Authn SAML request and match it to a client by this value.
 
 *Name*:: The name for the client in a {project_name} UI screen. To localize
 the name, set up a replacement string value. For example, a string value such as $\{myapp}.  See the link:{developerguide_link}[{developerguide_name}] for more information.

server_admin/topics/identity-broker/configuration.adoc

@@ -13,7 +13,7 @@ image:images/identity-providers.png[Identity Providers]
 +
 . Select an identity provider. {project_name} displays the configuration page for the identity provider you selected.
 +
-.Add facebook identity Provider
+.Add Facebook identity Provider
 image:images/add-identity-provider.png[Add Facebook Identity Provider]
 +
 When you configure an identity provider, the identity provider appears on the {project_name} login page as an option. You can place custom icons on the login screen for each identity provider. See  link:{developerguide_link}#custom-identity-providers-icons[custom icons] for more information.

server_admin/topics/identity-broker/first-login-flow.adoc

@@ -91,7 +91,7 @@ To disable user creation:
 This configuration also implies that {project_name} itself won't be able to determine which internal account would correspond to the external identity.
 Therefore, the `Verify Existing Account By Re-authentication` authenticator will ask the user to provide both username and password.
 
-[[_detect_existing_user_first_loging_flow]]
+[[_detect_existing_user_first_login_flow]]
 ==== Detect existing user first login flow
 In order to configure a first login flow in which:
 
@@ -109,6 +109,6 @@ Automatically sets an existing user to the authentication context without any ve
 You have to set the `First Login Flow` of the identity provider configuration to that flow.
 You could set the also set `Sync Mode` to `force` if you want to update the user profile (Last Name, First Name...) with the identity provider attributes.
 
-NOTE: This flow can be used if you want to delegate the identity to other identity providers (such as github, facebook ...) but you want to manage which users that can log in.
+NOTE: This flow can be used if you want to delegate the identity to other identity providers (such as GitHub, Facebook ...) but you want to manage which users that can log in.
 
 With this configuration, {project_name} is unable to determine which internal account corresponds to the external identity. The *Verify Existing Account By Re-authentication* authenticator asks the provider for the username and password.

server_admin/topics/identity-broker/social/github.adoc

@@ -3,7 +3,7 @@
 
 ==== GitHub
 
-To log in with Github, perform the following procedure.
+To log in with GitHub, perform the following procedure.
 
 .Procedure
 . Click *Identity Providers* in the menu.

server_admin/topics/identity-broker/social/instagram.adoc

@@ -44,7 +44,7 @@ image:images/instagram-create-instagram-app-id.png[Create a New Instagram App ID
 +
 .. Enter a value into *Display Name*.
 +
-.Setup the app
+.Set up the app
 image:images/instagram-app-settings.png[Setup the App]
 +
 .. Paste the *Redirect URL* from {project_name} into the *Valid OAuth Redirect URIs* field.

server_admin/topics/overview/concepts.adoc

@@ -5,7 +5,7 @@ Consider these core concepts and terms before attempting to use {project_name} t
 
 users::
   Users are entities that are able to log into your system.  They can have attributes associated with themselves like email,
-  username, address, phone number, and birth day.  They can be assigned group membership and have specific roles assigned to them.
+  username, address, phone number, and birthday.  They can be assigned group membership and have specific roles assigned to them.
 authentication::
   The process of identifying and validating a user.
 authorization::
@@ -16,7 +16,7 @@ credentials::
 roles::
   Roles identify a type or category of user.  `Admin`, `user`, `manager`, and `employee` are all typical roles that may exist
   in an organization.  Applications often assign access and permissions to specific roles rather than individual users as dealing
-  with users can be too fine grained and hard to manage.
+  with users can be too fine-grained and hard to manage.
 user role mapping::
   A user role mapping defines a mapping between a role and a user.  A user can be associated with zero or more roles.  This
   role mapping information can be encapsulated into tokens and assertions so that applications can decide access permissions on

server_admin/topics/realms.adoc

@@ -5,5 +5,5 @@ A realm manages a set of users, credentials, roles, and groups.  A user belongs
 and can only manage and authenticate the users that they control.  One {project_name} deployment can define, store, and manage as many realms
 as there is space for in the database.  When deciding whether to have one or more realms think about what kind of isolation you want to have for
 your users and applications.  For example, you might define a realm for the employees of your company and have a separate realm for your customers.
-You employees would log into the employee realm and only be able to visit internal company applications.  Customers would log into the customer
+Your employees would log into the employee realm and only be able to visit internal company applications.  Customers would log into the customer
 realm and only be able to interact with customer-facing apps.  In this section you'll learn some basics about realm creation and configuration.

server_admin/topics/realms/email.adoc

@@ -19,13 +19,13 @@ From::
   *From* denotes the address used for the *From* SMTP-Header for the emails sent.
 
 From display name::
-  *From display name* allows to configure a user friendly email address aliases (optional). If not set the plain *From* email address will be displayed in email clients.
+  *From display name* allows to configure a user-friendly email address aliases (optional). If not set the plain *From* email address will be displayed in email clients.
 
 Reply to::
   *Reply to* denotes the address used for the *Reply-To* SMTP-Header for the mails sent (optional). If not set the plain *From* email address will be used.
 
 Reply to display name::
-  *Reply to display name* allows to configure a user friendly email address aliases (optional). If not set the plain *Reply To* email address will be displayed.
+  *Reply to display name* allows to configure a user-friendly email address aliases (optional). If not set the plain *Reply To* email address will be displayed.
 
 Envelope from::
   *Envelope from* denotes the https://en.wikipedia.org/wiki/Bounce_address[Bounce Address] used for the *Return-Path* SMTP-Header for the mails sent (optional).

server_admin/topics/realms/keys.adoc

@@ -5,7 +5,7 @@ The authentication protocols that are used by {project_name} require cryptograph
 encryption.  {project_name} uses asymmetric key pairs, a private and public key, to accomplish this.
 
 {project_name} has a single active keypair at a time, but can have several passive keys as well. The active keypair
-is used to create new signatures, while the passive keypairs can be used to verify previous signatures. This makes it
+is used to create new signatures, while the passive keypair can be used to verify previous signatures. This makes it
 possible to regularly rotate the keys without any downtime or interruption to users.
 
 When a realm is created a key pair and a self-signed certificate is automatically generated.

server_admin/topics/realms/proc-using-admin-console.adoc

@@ -8,7 +8,7 @@ You configure realms and perform most administrative tasks in the {project_name}
 
 .Procedure
 
-. Go the the URL for the Admin Console.
+. Go to the URL for the Admin Console.
 +
 For example, for localhost, use this URL: http://localhost:8080{kc_admins_path}/
 +

server_admin/topics/realms/themes.adoc

@@ -17,7 +17,7 @@ Login theme::
   Username password entry, OTP entry, new user registration, and other similar screens related to login.
 
 Account theme::
-  Each user has an User Account Management UI.
+  Each user has a User Account Management UI.
 
 Admin console theme::
   The skin of the {project_name} Admin Console.

server_admin/topics/roles-groups/proc-creating-realm-roles.adoc

@@ -15,4 +15,4 @@ image:images/roles.png[]
 .Add role
 image:images/role.png[Add role]
 
-The *description* field can be localizable by specifying a substitution variable with `$\{var-name}` strings. The localized value is configured to your theme within the themes property files. See the link:{developerguide_link}[{developerguide_name}] for more details.
+The *description* field can be localized by specifying a substitution variable with `$\{var-name}` strings. The localized value is configured to your theme within the themes property files. See the link:{developerguide_link}[{developerguide_name}] for more details.

server_admin/topics/sso-protocols/con-oidc-auth-flows.adoc

@@ -13,7 +13,7 @@ The Authorization Code Flow is a browser-based protocol and suits authenticating
 . A user connects to an application using a browser. The application detects the user is not logged into the application.
 . The application redirects the browser to {project_name} for authentication.
 . The application passes a callback URL as a query parameter in the browser redirect. {project_name} uses the parameter upon successful authentication.
-. {project_name} authenticates the user and creates a one-time, short lived, temporary code.
+. {project_name} authenticates the user and creates a one-time, short-lived, temporary code.
 . {project_name} redirects to the application using the callback URL and adds the temporary code as a query parameter in the callback URL.
 . The application extracts the temporary code and makes a background REST invocation to {project_name}
 to exchange the code for an _identity_ and _access_ and _refresh_ token.  To prevent replay attacks, the temporary code cannot be used more than once.
@@ -304,7 +304,7 @@ Again since all of this is described in the OIDC specification we will only give
 ===== Session Management
 
 This is a browser-based logout. The application obtains session status information from {project_name} at a regular basis.
-When the session is terminated at {project_name} the application will notice and trigger it's own logout.
+When the session is terminated at {project_name} the application will notice and trigger its own logout.
 
 ===== RP-Initiated Logout
 
@@ -312,7 +312,7 @@ This is also a browser-based logout where the logout starts by redirecting the u
 This redirect usually happens when the user clicks the `Log Out` link on the page of some application, which previously used {project_name} to authenticate the user.
 
 Once the user is redirected to the logout endpoint, {project_name} is going to send logout requests to
-clients to let them to invalidate their local user sessions, and potentially redirect the user to some URL
+clients to let them invalidate their local user sessions, and potentially redirect the user to some URL
 once the logout process is finished. The user might be optionally requested to confirm the logout in case the  `id_token_hint` parameter was not used.
 After logout, the user is automatically redirected to the specified `post_logout_redirect_uri` as long as it is provided as a parameter.
 Note that you need to include either the `client_id` or `id_token_hint` parameter in case the `post_logout_redirect_uri` is included. Also the `post_logout_redirect_uri` parameter
@@ -322,7 +322,7 @@ Depending on the client configuration, logout requests can be sent to clients th
 Session Management described in the previous section, {project_name} does not need to send any logout requests to them; these clients automatically detect that SSO session
 in the browser is logged out.
 
-===== Frontchannel Logout
+===== Front-channel Logout
 
 To configure clients to receive logout requests through the front-channel, look at the <<_front-channel-logout, Front-Channel Logout>> client setting. When using this method, consider the following:
 
@@ -342,7 +342,7 @@ using the <<_back-channel-logout-url, Back-Channel Logout URL>>. If not defined,
 
 ===== Backchannel Logout
 
-This is a non browser-based logout that uses direct backchannel communication between {project_name} and clients. 
+This is a non-browser-based logout that uses direct backchannel communication between {project_name} and clients.
 {project_name} sends a HTTP POST request containing a logout token to all clients logged into {project_name}. These
 requests are sent to a registered backchannel logout URLs at {project_name} and are supposed to trigger a logout at client side.
 

server_admin/topics/sso-protocols/con-saml.adoc

@@ -8,6 +8,6 @@ link:http://saml.xml.org/saml-specifications[SAML 2.0] is a similar specificatio
 
 In general, SAML implements two use cases. 
 
-The first use case is an application that requests the {project_name} server authenticates a user.  Upon successful login, the application will receive an XML document. This document contains an SAML assertion that specifies user attributes. The realm digitally signs the the document which contains access information (such as user role mappings) that applications use to determine the resources users are allowed to access in the application.
+The first use case is an application that requests the {project_name} server authenticates a user.  Upon successful login, the application will receive an XML document. This document contains an SAML assertion that specifies user attributes. The realm digitally signs the document which contains access information (such as user role mappings) that applications use to determine the resources users are allowed to access in the application.
 
 The second use case is a client accessing remote services.  The client requests a SAML assertion from {project_name} to invoke on remote services on behalf of the user.

server_admin/topics/sso-protocols/oidc.adoc

@@ -38,16 +38,16 @@ heavy use of browser redirects to obtain an _identity_ and _access_ token.  Here
 . Browser visits application.  The application notices the user is not logged in, so it redirects the browser to {project_name}
   to be authenticated.  The application passes along a callback URL (a redirect URL) as a query parameter in this browser redirect
   that {project_name} will use when it finishes authentication.
-. {project_name} authenticates the user and creates a one-time, very short lived, temporary code.  {project_name}
+. {project_name} authenticates the user and creates a one-time, very short-lived, temporary code.  {project_name}
   redirects back to the application using the callback URL provided earlier and additionally adds the temporary code
   as a query parameter in the callback URL.
 . The application extracts the temporary code and makes a background out of band REST invocation to {project_name}
   to exchange the code for an _identity_, _access_ and _refresh_ token.  Once this temporary code has been used once
   to obtain the tokens, it can never be used again.  This prevents potential replay attacks.
 
-It is important to note that _access_ tokens are usually short lived and often expired after only minutes.  The additional _refresh_
+It is important to note that _access_ tokens are usually short-lived and often expired after only minutes.  The additional _refresh_
 token that was transmitted by the login protocol allows the application to obtain a new access token after it expires.  This
-refresh protocol is important in the situation of a compromised system.  If access tokens are short lived, the whole system is only
+refresh protocol is important in the situation of a compromised system.  If access tokens are short-lived, the whole system is only
 vulnerable to a stolen token for the lifetime of the access token.  Future refresh token requests will fail if an admin
 has revoked access.  This makes things more secure and more scalable.
 
@@ -330,14 +330,14 @@ Again since all of this is described in the OIDC specification we will only give
 ===== Session Management
 
 This is a browser-based logout. The application obtains session status information from {project_name} at a regular basis.
-When the session is terminated at {project_name} the application will notice and trigger it's own logout.
+When the session is terminated at {project_name} the application will notice and trigger its own logout.
 
 ===== Front-Channel Logout
 
 This is also a browser-based logout where the logout starts by redirecting the user to a specific endpoint at {project_name}.
 
 Once the user is redirected to the logout endpoint, {project_name} is going to send logout requests to
-clients to let them to invalidate their local user sessions, and potentially redirect the user to some URL
+clients to let them invalidate their local user sessions, and potentially redirect the user to some URL
 once the logout process is finished.
 
 Depending on the client configuration, logout requests can be sent to clients through the front-channel or through the back-channel.
@@ -360,7 +360,7 @@ using the <<_back-channel-logout-url, Back-Channel Logout URL>>. If not defined,
 
 ===== Backchannel Logout
 
-This is a non browser-based logout that uses direct backchannel communication between {project_name} and clients. 
+This is a non-browser-based logout that uses direct backchannel communication between {project_name} and clients.
 {project_name} sends a HTTP POST request containing a logout token to all clients logged into {project_name}. These
 requests are sent to a registered backchannel logout URLs at {project_name} and are supposed to trigger a logout at client side.
 

server_admin/topics/threat/brute-force.adoc

@@ -89,9 +89,9 @@ When {project_name} disables a user, the user cannot log in until an administrat
 .. Increment `count`
 .. Calculate `wait` using _Wait Increment_ * (`count` / _Max Login Failures_). The division is an integer division rounded down to a whole number
 .. If `wait` equals 0 and the time between this failure and the last failure is less than _Quick Login Check Milliseconds_, set `wait` to _Minimum Quick Login Wait_.
-... Temporarily disable the user for the smaller of `wait` and _Max Wait_ seconds
+... Temporarily disable the user for the smallest of `wait` and _Max Wait_ seconds
 
-'count` does not increment when a temporarily disabled account commits a login failure.
+`count` does not increment when a temporarily disabled account commits a login failure.
 ====
 
 The downside of {project_name} brute force detection is that the server becomes vulnerable to denial of service attacks. When implementing a denial of service attack, an attacker can attempt to log in by guessing passwords for any accounts it knows and eventually causing {project_name} to disable the accounts.

server_admin/topics/threat/read-only-attributes.adoc

@@ -37,7 +37,7 @@ kc.[sh|bat] start --spi-user-profile-legacy-user-profile-read-only-attributes=fo
 ----
 
 For this example, users and administrators would not be able to update attribute `foo`. Users would not be able to edit any attributes starting with the `bar`.
-So for example `bar` or `barrier`. Configuration is case insensitive, so attributes like `FOO` or `BarRier` will be denied as well for this example. The wildcard character `\*` is supported
+So for example `bar` or `barrier`. Configuration is case-insensitive, so attributes like `FOO` or `BarRier` will be denied as well for this example. The wildcard character `\*` is supported
 only at the end of the attribute name, so the administrator can effectively deny all the attributes starting with the specified character. The `*` in the middle of the attribute is considered
 as a normal character.
 

server_admin/topics/users/proc-creating-user.adoc

@@ -27,7 +27,7 @@ ifdef::api-management[]
 . Toggle *Email Verified* to *ON*.
 . Click *Save*.
 . In the *Credentials* tab, set the password in both fields.
-.. Toggle *Temporary* to *OFF* to avoid resetting the password during the next log in.
+.. Toggle *Temporary* to *OFF* to avoid resetting the password during the next login.
 .. Click *Reset Password*.
 .. Click *Change Password*.
 .. Click *Save*.

server_admin/topics/users/proc-enabling-recaptcha.adoc

@@ -27,7 +27,7 @@ NOTE: The localhost works by default. You do not have to specify a domain.
 . Click the *Flows* tab.
 . Select *Registration* from the list.
 . Set the *reCAPTCHA* requirement to *Required*. This enables
-reCAPTCHA.  
+reCAPTCHA.
 . Click the *gear icon* ⚙️ on the *reCAPTCHA* row.
 . Click the *Config* link.
 

server_admin/topics/users/user-profile.adoc

@@ -233,7 +233,7 @@ image:images/user-profile-validation.png[]
 In order to pass additional information to frontends, attributes can be decorated with
 annotations to dictate how attributes are rendered. This capability is mainly useful when extending {project_name} themes
 to render pages dynamically based on the annotations associated with attributes.
-This mechanism is used for example to link:#_configurin_form_input_field_for_attribute[configure Form input filed for attribute].
+This mechanism is used for example to link:#_configuring_form_input_field_for_attribute[configure Form input filed for attribute].
 
 .Attribute Annotation
 image:images/user-profile-annotation.png[]
@@ -464,7 +464,7 @@ image:images/user-profile-update-profile.png[]
 When attributes are linked to an attribute group, the attribute order is also important to make sure attributes within the same group are close together, within a same group header. Otherwise, if attributes within a group do not have a sequential order you might have the same group header rendered multiple times in the dynamic form.
 ====
 
-[[_configurin_form_input_field_for_attribute]]
+[[_configuring_form_input_field_for_attribute]]
 === Configuring Form input filed for Attributes
 
 {project_name} provides built-in annotations to configure which input type will be used for the attribute in dynamic forms and other aspects of it's visualization.
@@ -500,7 +500,7 @@ Text is NOT html escaped when rendered into the page, so you can use html tags h
 or a short description of the expected format). The short hint is displayed in the input field before the user enters a value.
 
 |inputTypeSize
-|HTML input `size` attribute applied to the field - specifies the width, in characters, of an single line input field. For fields based on HTML `select` type
+|HTML input `size` attribute applied to the field - specifies the width, in characters, of a single line input field. For fields based on HTML `select` type
 it specifies number of rows with options shown. May not work, depending on css in used theme!
 
 |inputTypeCols
@@ -621,8 +621,8 @@ Available `inputType` annotation values:
 Options for select and multiselect fields are taken from validation applied to the attribute to be
 sure validation and field options presented in UI are always consistent. By default, options are taken from built-in `options` validation.
 
-You can use various ways to provide nice human readable labels for select and multiselect options. The simplest
-case is when attribute values are same as UI labels. No any extra configuration is necessary in this case.
+You can use various ways to provide nice human-readable labels for select and multiselect options. The simplest
+case is when attribute values are same as UI labels. No extra configuration is necessary in this case.
 
 .Option values same as UI labels
 image:images/user-profile-select-options-simple.png[]
@@ -726,7 +726,7 @@ When enabled, the `VerifyProfile` action is going to perform the following steps
 By default, the `VerifyProfile` action is disabled. To enabled it, click on the
 `Authentication` link on the left side menu and then click on the `Required Actions` tab. At this tab, select the *Enabled* switch of the `VerifyProfile` action.
 
-.Registring the VerifyProfile Required Action
+.Registering the VerifyProfile Required Action
 image:images/user-profile-register-verify-profile-action.png[]
 
 == Migrating to User Profile