INcorporates feedback (#40)

server_admin/topics/clients/con-client-scopes.adoc

@@ -4,27 +4,27 @@
 === Client Scopes
 
 [role="_abstract"]
-{project_name} allows you to define a shared client configuration in an entity called a _client scope_. This entity allows you to configure <<_protocol-mappers, protocol mappers>> and <<_role_scope_mappings, role scope mappings>> for multiple clients.
+Use {project_name} to define a shared client configuration in an entity called a _client scope_. A _client scope_ configures <<_protocol-mappers, protocol mappers>> and <<_role_scope_mappings, role scope mappings>> for multiple clients.
 
-Client scopes also support the OAuth 2 *scope* parameter. This parameter allows client applications to request more or fewer claims or roles in the access token, depending on the requirement of the application.
+Client scopes also support the OAuth 2 *scope* parameter. Client applications use this parameter to request claims or roles in the access token, depending on the requirement of the application.
 
 include::proc-creating-client-scopes.adoc[]
 
 ==== Protocol
-When you create a client scope, you must choose the *Protocol*. Clients linked in the same scope must have the same protocol.
+When you create a client scope, choose the *Protocol*. Clients linked in the same scope must have the same protocol.
 
 Each realm has a set of pre-defined built-in client scopes in the menu.
 
 * SAML protocol: The *role_list*. This scope contains one protocol mapper for  the roles list in the SAML assertion.
-* OpenID Connect protocol: There are several client scopes:
+* OpenID Connect protocol: Several client scopes are available:
 ** *roles*
 +
-This scope is not defined in the OpenID Connect specification and is not added automatically to the *scope* claim in the access token. This scope has  mappers, which are used to add the roles of the user to the access token and
-add audiences for clients that have at least one client role. This is described in more detail in the <<_audience_resolve, Audience section>>.
+This scope is not defined in the OpenID Connect specification and is not added automatically to the *scope* claim in the access token. This scope has mappers, which are used to add the roles of the user to the access token and
+add audiences for clients that have at least one client role. These mappers are described in more detail in the <<_audience_resolve, Audience section>>.
 +
 ** *web-origins*
 +
-This scope is also not defined in the OpenID Connect specification and not added to the *scope* claimin the access token. This scope is used to add allowed web origins to the access token *allowed-origins* claim.
+This scope is also not defined in the OpenID Connect specification and not added to the *scope* claiming the access token. This scope is used to add allowed web origins to the access token *allowed-origins* claim.
 +
 ** *microprofile-jwt*
 +
@@ -51,23 +51,23 @@ When the *phone* client scope is linked to a client, the client automatically in
 Built-in client scopes contain the protocol mappers as defined in the specification. You are free to edit client scopes and create, update, or remove any protocol mappers or role scope mappings.
 
 ==== Consent related settings
-Client scopes contain options related to the consent screen. Those options are useful if the linked client if the *Consent Required* switch is enabled on the client.
+Client scopes contain options related to the consent screen. Those options are useful if the linked client if *Consent Required* is enabled on the client.
 
 Display On Consent Screen::
-  If this switch is set to ON, and the scope is added to a client that requires consent, the text specified in *Consent Screen Text* will be displayed on the consent screen. This text is shown when the user is authenticated and before the user is redirected from {project_name} to the client. If this switch is OFF, this client scope will not be displayed on the consent screen.
+  If *Display On Consent Screen* is enabled, and the scope is added to a client that requires consent, the text specified in *Consent Screen Text* will be displayed on the consent screen. This text is shown when the user is authenticated and before the user is redirected from {project_name} to the client. If *Display On Consent Screen* is disabled, this client scope will not be displayed on the consent screen.
 
 Consent Screen Text::
   The text displayed on the consent screen when this client scope is added to a client when consent required defaults to the name of client scope. The value for this text can be customised by specifying a substitution variable with *${var-name}* strings. The customised value is  configured within the property files in your theme. See the  link:{developerguide_link}[{developerguide_name}] for more information on customisation.
 
 [[_client_scopes_linking]]
 ==== Link Client Scope with the Client
-Linking between a client scope and a client is configured in the *Client Scopes* tab of the client. There are 2 ways of linking between client scope and client.
+Linking between a client scope and a client is configured in the *Client Scopes* tab of the client. Two ways of linking between client scope and client are available.
 
 Default Client Scopes::
-This is applicable to the OpenID Connect and SAML clients. Default client scopes are applied when issuing OpenID Connect tokens or SAML assertions for a client. The client will inherit Protocol Mappers and Role Scope Mappings that are defined on the client scope. For the OpenID Connect Protocol, the Mappers and Role Scope Mappings are always applied, regardless of the value used for the scope parameter in the OpenID Connect authorization request.
+This setting is applicable to the OpenID Connect and SAML clients. Default client scopes are applied when issuing OpenID Connect tokens or SAML assertions for a client. The client will inherit Protocol Mappers and Role Scope Mappings that are defined on the client scope. For the OpenID Connect Protocol, the Mappers and Role Scope Mappings are always applied, regardless of the value used for the scope parameter in the OpenID Connect authorization request.
 
 Optional Client Scopes::
-This is applicable only for OpenID Connect clients. Optional client scopes are applied when issuing tokens for this client but only when requested by the *scope* parameter in the OpenID Connect authorization request.
+This setting is applicable only for OpenID Connect clients. Optional client scopes are applied when issuing tokens for this client but only when requested by the *scope* parameter in the OpenID Connect authorization request.
 
 ===== Example
 For this example, assume the client has *profile* and *email* linked as default client scopes, and *phone* and *address* linked as optional client scopes. The client uses the value of the scope parameter when sending a request to the OpenID Connect authorization endpoint.
@@ -98,7 +98,7 @@ Client scope::
 Client scopes are entities in {project_name} that are configured at the realm level and can be linked to clients. Client scopes are referenced by their name when a request is sent to the {project_name} authorization endpoint with a corresponding value of the *scope* parameter. See the <<_client_scopes_linking, client scopes linking>> section for more details.
 
 Role scope mapping::
-Available under the *Scope* tab of a client or client scope. Role scope mapping allows you to limit the roles which can be used in the access tokens. See the <<_role_scope_mappings, Role Scope Mappings section>> for more details.
+This is available under the *Scope* tab of a client or client scope. Use *Role scope mapping* to limit the roles that can be used in the access tokens. See the <<_role_scope_mappings, Role Scope Mappings section>> for more details.
 
 ifeval::[{project_community}==true]
 

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

@@ -6,13 +6,13 @@
 [role="_abstract"]
 Applications receiving ID tokens, access tokens, or SAML assertions may require different roles and user metadata. 
 
-{project_name} allows you to:
+You can use {project_name} to:
 
 * Hardcode roles, claims and custom attributes.
 * Pull user metadata into a token or assertion.
 * Rename roles.
 
-You can do this in the *Mappers* tab in the Admin Console
+You perform these actions in the *Mappers* tab in the Admin Console.
 
 .Mappers Tab
 image:{project_images}/mappers-oidc.png[]
@@ -20,16 +20,16 @@ image:{project_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 can add pre-configured mappers by clicking the *Add Builtin* button.
+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. There are additional settings available, depending on the mapper type. Click the *Edit* button next to a mapper to access the configuration screen to adjust these settings.
+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.
 
 .Mapper Config
 image:{project_images}/mapper-config.png[]
 
 Details on each option can be viewed by hovering over its tooltip.
 
-Many OIDC mappers allow you to control where the claim gets placed. You can opt to include or exclude the claim from the _id_ and _access_ tokens by adjusting the *Add to ID token* and *Add to access token* switches.
+Use OIDC mappers to control where the claim gets placed. You opt to include or exclude the claim from the _id_ and _access_ tokens by adjusting the *Add to ID token* and *Add to access token* switches.
 
 include::proc-creating-mappers.adoc[]
 
@@ -37,8 +37,7 @@ include::proc-creating-mappers.adoc[]
 
 Mapper implementations have _priority order_. _Priority order_ is not the configuration property of the mapper. It is the property of the concrete implementation of the mapper.
 
-Mappers are sorted by the order in the list of mappers. The changes in the token or assertion are applied in that order with the lowest applying first. This means that implementations that are dependent on other
-implementations are processed in the necessary order.
+Mappers are sorted by the order in the list of mappers. The changes in the token or assertion are applied in that order with the lowest applying first. Therefore, the implementations that are dependent on other implementations are processed in the necessary order.
 
 For example, to compute the roles which will be included with a token:
 
@@ -48,7 +47,7 @@ For example, to compute the roles which will be included with a token:
 [[_protocol-mappers_oidc-user-session-note-mappers]]
 ==== OIDC User Session Note Mappers
 
-User session details are defined using mappers and are automatically included when you use or enable a feature on a client. You can click the *Add builtin* button to include session details.
+User session details are defined using mappers and are automatically included when you use or enable a feature on a client. Click *Add builtin* to include session details.
 
 Impersonated user sessions provide the following details:
 
@@ -63,6 +62,6 @@ Service account sessions provide the following details:
 
 ==== Script Mapper
 
-The *Script Mapper* allows you to map claims to tokens by running user-defined JavaScript code. For more details about deploying scripts to the server, see link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}].
+Use the *Script Mapper* to map claims to tokens by running user-defined JavaScript code. For more details about deploying scripts to the server, see link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}].
 
 When scripts deploy, you should be able to select the deployed scripts from the list of available mappers.

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

@@ -75,7 +75,7 @@ The procedure is:
 
 . Open the client's *Credentials* tab.
 . Select *Signed Jwt* from the *Client Authenticator* menu.
-. Set the *JWKS URL* switch to ON.
+. Toggle *JWKS URL* to ON.
 . Input the client's public key URL in the *JWKS URL* textbox.
 
 Key Encryption's algorithms are defined in the https://tools.ietf.org/html/rfc7518#section-4.1[Json Web Algorithm (JWA)] specification. {project_name} supports:

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

@@ -6,7 +6,7 @@
 [role="_abstract"]
 Typically, the environment where {project_name} is deployed consists of a set of _confidential_ or _public_ client applications that use {project_name} for authentication.
 
-There are also _services_ (_Resource Servers_ in the https://tools.ietf.org/html/draft-ietf-oauth-mtls-08#section-4.2[OAuth 2 specification]) that serve requests from client applications and provide resources to these applications. These services require an _Access token_ (Bearer token) to be sent to them to authenticate a request. This token is obtained by the frontend application upon login to {project_name}.
+_Services_ (_Resource Servers_ in the https://tools.ietf.org/html/draft-ietf-oauth-mtls-08#section-4.2[OAuth 2 specification]) are also available that serve requests from client applications and provide resources to these applications. These services require an _Access token_ (Bearer token) to be sent to them to authenticate a request. This token is obtained by the frontend application upon login to {project_name}.
 
 In the environment where trust among services is low, you may encounter this scenario:
 
@@ -24,9 +24,9 @@ In the environment where trust among services is low, you may encounter this sce
 
 This scenario is unlikely in environments with a high level of trust between services but not in environments where trust is low. In some environments, this workflow may be correct as the untrusted service may have to retrieve data from a trusted service to return data to the original client application.
 
-An unlimited audience is useful when a high level of trust exists between services. Otherwise, the audience should be limited. You can limit the audience and, at the same time, allow untrusted services to retrieve data from trusted services. In this case, you must ensure that the untrusted service and the trusted service are added as audiences to the token.
+An unlimited audience is useful when a high level of trust exists between services. Otherwise, the audience should be limited. You can limit the audience and, at the same time, allow untrusted services to retrieve data from trusted services. In this case, ensure that the untrusted service and the trusted service are added as audiences to the token.
 
-To prevent any misuse of the access token, limit the audience on the token and configure your services to verify the audience on the token. This will change the flow like this:
+To prevent any misuse of the access token, limit the audience on the token and configure your services to verify the audience on the token. The flow will change as follows:
 
 . A frontend application authenticates against {project_name}.
 
@@ -38,7 +38,7 @@ The token issued to the application contains a reference to the untrusted servic
 +
 .The untrusted service serves the request to the client application but also keeps the token.
 
-. The untrusted service invokes a trusted service with the token. Invocation is not successful because the trusted service checks the audience on the token and find that its audience is only for the untrusted service. This is expected behavior and security is not broken.
+. The untrusted service invokes a trusted service with the token. Invocation is not successful because the trusted service checks the audience on the token and find that its audience is only for the untrusted service. This behavior is expected and security is not broken.
 
 If the client wants to invoke the trusted service later, it must obtain another token by reissuing the SSO login with *scope=<trusted service>*. The returned token will then contain the trusted service as an audience:
 
@@ -46,7 +46,7 @@ If the client wants to invoke the trusted service later, it must obtain another
 ----
 "audience": [ "<trusted service>" ]
 ----
-Use this to invoke the *<trusted service>*.
+Use this value to invoke the *<trusted service>*.
 
 ===== Setup
 
@@ -59,7 +59,7 @@ When setting up audience checking:
 [[_audience_resolve]]
 ===== Automatically add audience
 
-An _Audience Resolve_ protocol mapper is defined in the default client scope _roles_. The mapper checks for clients that have at least one client role available for the current token. The client ID of each client is then added as an audience. This is useful if your service (usually bearer-only) clients rely on client roles.
+An _Audience Resolve_ protocol mapper is defined in the default client scope _roles_. The mapper checks for clients that have at least one client role available for the current token. The client ID of each client is then added as an audience, which is useful if your service (usually bearer-only) clients rely on client roles.
 
 For example, for a bearer-only client and a confidential client,
 you can use the access token issued for the confidential client to invoke the bearer-only client REST service. The bearer-only client will be automatically added as an audience to the access token issued for the confidential client if the following are true:
@@ -79,8 +79,7 @@ Assuming that the client scope is added as an optional client scope to the confi
 
 [NOTE]
 ====
-The frontend client itself is not automatically added to the access token audience. This allows for easy differentiation between
-the access token and the ID token, since the access token will not contain the client for which the token is issued as an audience.
+The frontend client itself is not automatically added to the access token audience, therefore allowing easy differentiation between the access token and the ID token, since the access token will not contain the client for which the token is issued as an audience.
 
 If you need the client itself as an audience, see the
 <<_audience_hardcoded, hardcoded audience>> option. However, using the same client as both frontend and REST service is not recommended.
@@ -112,12 +111,11 @@ See <<_client_scopes_linking, Client Scopes Linking section>> for more details.
 
 * You can optionally <<_client_scopes_evaluate, Evaluate Client Scopes>> and generate an example access token. *good-service* will be added to the audience of the generated access token if *good-service* is included in the _scope_ parameter, when you assigned it as an optional client scope.
 
-* In your *my-app* application, you must ensure that the _scope_ parameter is used. The value *good-service* must be included when you want to issue the token for accessing *good-service*. 
+* In your *my-app* application, ensure that the _scope_ parameter is used. The value *good-service* must be included when you want to issue the token for accessing *good-service*. 
 +
 See:
 +
 ** link:{adapterguide_link}#_params_forwarding[parameters forwarding section] if your application uses the servlet adapter.
 ** link:{adapterguide_link}#_javascript_adapter[javascript adapter section] if your application uses the javascript adapter.
 
-NOTE: Both the _Audience_ and _Audience Resolve_ protocol mappers add the audiences to the access token only, by default. The ID Token
-typically contains only a single audience, the client ID for which the token was issued. This is a requirement of the OpenID Connect specification. However, the access token does not necessarily have the client ID, which was the token issued for, unless the audience mappers added it.
+NOTE: Both the _Audience_ and _Audience Resolve_ protocol mappers add the audiences to the access token only, by default. The ID Token typically contains only a single audience, the client ID for which the token was issued, a requirement of the OpenID Connect specification. However, the access token does not necessarily have the client ID, which was the token issued for, unless the audience mappers added it.

server_admin/topics/clients/oidc/con-confidential-client-credentials.adoc

@@ -13,7 +13,7 @@ The *Client Authenticator* drop-down list specifies the type of credential to us
 
 *Client ID and Secret*
 
-This choice is the default setting. The secret is automatically generated for you and the *Regenerate Secret* button recreates the secret if necessary.
+This choice is the default setting. The secret is automatically generated for you and the clicking *Regenerate Secret*  recreates the secret if necessary.
 
 *Signed JWT*
 
@@ -22,7 +22,7 @@ image:{project_images}/client-credentials-jwt.png[]
 
 *Signed JWT* is "Signed Json Web Token".
 
-To use the *Signed JWT* credential type, a private key and certificate must be generated for the client. The private key is used to sign the JWT and the certificate is used by the server to verify the signature. Click the *Generate new keys and certificate* button to begin this process.
+To use the *Signed JWT* credential type, a private key and certificate must be generated for the client. The private key is used to sign the JWT and the certificate is used by the server to verify the signature. Click *Generate new keys and certificate* to begin this process.
 
 .Generate Keys
 image:{project_images}/generate-client-keys.png[]
@@ -32,19 +32,19 @@ image:{project_images}/generate-client-keys.png[]
 . Enter a store password.
 . Click *Generate and Download*.
 
-When you generate the keys, {project_name} will store the certificate and you must download the private key and certificate for your client.
+When you generate the keys, {project_name} will store the certificate and you download the private key and certificate for your client.
 
-You can also generate keys using an external tool and then import the client's certificate by clicking the *Import Certificate* button.
+You can also generate keys using an external tool and then import the client's certificate by clicking *Import Certificate*.
 
 .Import Certificate
 image:{project_images}/import-client-cert.png[]
 
 . Select the archive format of the certificate.
 . Enter the store password.
-. Select the certificate file by clicking the *Import File* button.
+. Select the certificate file by clicking *Import File*.
 . Click *Import*.
 
-It is not necessary to import a certificate if you click the *Use JWKS URL* switch. In this case, you can provide the URL where the public key is published in https://self-issued.info/docs/draft-ietf-jose-json-web-key.html[JWK] format. With this option, if the key is ever changed, {project_name} reimports the key.
+Importing a certificate is unnecessary if you click *Use JWKS URL*. In this case, you can provide the URL where the public key is published in https://self-issued.info/docs/draft-ietf-jose-json-web-key.html[JWK] format. With this option, if the key is ever changed, {project_name} reimports the key.
 
 If you are using a client secured by {project_name} adapter, you can configure the JWKS URL in this format, assuming that https://myhost.com/myapp is the root URL of your client application:
 
@@ -55,7 +55,7 @@ https://myhost.com/myapp/k_jwks
 
 See link:{developerguide_link}[{developerguide_name}] for more details.
 
-WARNING: {project_name} caches public keys of OIDC clients. If the private key of your client is compromised, you must update your keys and clear the key cache. See <<_clear-cache, Clearing the cache>> section for more details.
+WARNING: {project_name} caches public keys of OIDC clients. If the private key of your client is compromised, update your keys and clear the key cache. See <<_clear-cache, Clearing the cache>> section for more details.
 
 *Signed JWT with Client Secret*
 

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

@@ -4,7 +4,7 @@
 To protect an application that uses the OpenID connect protocol, you create a client.
 
 .Procedure
-. Click *Clients* in the left navigation pane.  
+. Click *Clients* in the menu.  
 
 . Click *Create* to go to the *Add Client* page.
 +
@@ -47,4 +47,3 @@ image:{project_images}/client-settings-oidc.png[Client Settings]
 * For more information about fields on the *Settings* tab, see xref:con-basic-settings_{context}[Basic Settings].
 * For more information about the OIDC protocol, see xref:con-oidc_{context}[OpenID Connect].
 endif::[]
-

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

@@ -2,7 +2,7 @@
 [[_service_accounts]]
 ==== Using a Service Account
 [role="_abstract"]
-Each OIDC client has a built-in _service account_, which allows it to obtain an access token.
+Each OIDC client has a built-in _service account_. Use this _service account_ to obtain an access token.
 
 .Prerequisites
 
@@ -10,11 +10,11 @@ Each OIDC client has a built-in _service account_, which allows it to obtain an
 . Select your client in {project_name}.
 . Click on the *Settings* tab.
 . Set the <<_access-type, Access Type>> of your client is set to *confidential*.
-. Set the *Service Accounts Enabled* switch to ON.
+. Toggle *Service Accounts Enabled* to ON.
 . Click *Save*.
 . Configure your <<_client-credentials, client credentials>>.
 . Click on the *Scope* tab.
-. Verify that you have roles or set Full Scope Allowed to ON.
+. Verify that you have roles or toggle *Full Scope Allowed* to ON.
 . On the *Service Account Roles* tab, configure the roles available to this service account for your client.
 
 Roles from access tokens are the intersection of:

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

@@ -5,7 +5,7 @@
 Each OIDC client has a built-in _service account_ which allows it to obtain an access token.
 This is covered in the OAuth 2.0 specifiation under <<_client_credentials_grant,Client Credentials Grant>>.
 To use this feature you must set the <<_access-type, Access Type>> of your client to `confidential`.  When you do this,
-the `Service Accounts Enabled` switch will appear.  You need to turn on this switch.  Also make sure that you have
+the `Service Accounts Enabled` switch is displayed.  You need to toggle this switch to ON.  Also make sure that you have
 configured your <<_client-credentials, client credentials>>.
 
 To use it you must have registered a valid `confidential` Client and you need to check the switch `Service Accounts Enabled` in {project_name} admin console for this client.

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

@@ -3,7 +3,7 @@
 [role="_abstract"]
 To create a client scope, follow these steps:
 
-. Click *Client Scopes* in the left toolbar. 
+. Click *Client Scopes* in the menu. 
 +
 .Client Scopes List
 image:{project_images}/client-scopes-list.png[]

server_admin/topics/clients/proc-creating-mappers.adoc

@@ -5,7 +5,7 @@ You can add mapper types as follows:
 
 .Procedure
 . Go to the *Mappers* tab.
-. Click the *Create* button.
+. Click *Create*.
 +
 .Add Mapper
 image:{project_images}/add-mapper.png[]

server_admin/topics/clients/proc-updating-default-scopes.adoc

@@ -1,7 +1,7 @@
 [id="proc_updating_client_scopes_{context}"]
 
 [role="_abstract"]
-*Realm Default Client Scopes* allow you to define sets of client scopes which are automatically linked to newly created clients.
+Use *Realm Default Client Scopes* to define sets of client scopes that are automatically linked to newly created clients.
 
 .Procedure
 . Click the *Client Scopes* tab for the client.

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

@@ -6,7 +6,7 @@
 POST and Redirect bindings are supported. You can choose to require client signature validation. You can have the server sign and/or encrypt responses as well.
 
 .Procedure
-. Click *Clients* in the left navigation pane.  
+. Click *Clients* in the menu.  
 
 . Click *Create* to go to the *Add Client* page.
 +
@@ -38,7 +38,7 @@ the name, set up a replacement string value. For example, a string value such as
 *Consent Required*:: When set to ON, users see a consent page that grants access to that application.  The page also displays the metadata of the information that the client can access. If you have ever done a social login to Facebook, you often see a similar page. Red Hat Single Sign-On provides the same functionality.
 
 *Include AuthnStatement*:: SAML login responses may specify the  authentication method used, such as password, as well as timestamps of the login and the session expiration.
-This switch is enabled by default, so that the *AuthnStatement* element will be included in login responses. Setting this to OFF prevents clients from determining the maximum session length, which can create client sessions that do not expire.
+*Include AuthnStatement* is enabled by default, so that the *AuthnStatement* element will be included in login responses. Setting this to OFF prevents clients from determining the maximum session length, which can create client sessions that do not expire.
 
 *Sign Documents*:: When set to ON, {project_name} signs the document using the realms private key.
 
@@ -64,19 +64,19 @@ This option is used when {project_name} server and adapter provide the IDP and S
 
 *Encrypt Assertions*:: Encrypts the assertions in SAML documents with the realms private key. The AES algorithm uses a key size of 128 bits. 
 
-*Client Signature Required*:: If this switch is set to ON, documents coming from a client are expected to be signed. {project_name} validates this signature using the client public key or certificate set up in the *SAML Keys* tab.
+*Client Signature Required*:: If *Client Signature Required* is enabled, documents coming from a client are expected to be signed. {project_name} validates this signature using the client public key or certificate set up in the *SAML Keys* tab.
 
-*Force POST Binding*:: By default, {project_name} responds using the initial SAML binding of the original request. By setting this switch to ON, {project_name} responds using the SAML POST binding even if the original request used the redirect binding.
+*Force POST Binding*:: By default, {project_name} responds using the initial SAML binding of the original request. By enabling *Force POST Binding*, {project_name} responds using the SAML POST binding even if the original request used the redirect binding.
 
-*Front Channel Logout*:: If this switch is set to ON, the application requires a browser redirect to perform a logout. For example, the application may require a cookie to be reset which could only be done via a redirect. If this switch is set to OFF, {project_name} invokes a background SAML request to log out of the application.
+*Front Channel Logout*:: If *Front Channel Logout* is enabled, the application requires a browser redirect to perform a logout. For example, the application may require a cookie to be reset which could only be done via a redirect. If *Front Channel Logout* is disabled, {project_name} invokes a background SAML request to log out of the application.
 
-*Force Name ID Format*:: If a request has a name ID policy, ignore it and use the value configured in the admin console under *Name ID Format*.
+*Force Name ID Format*:: If a request has a name ID policy, ignore it and use the value configured in the Admin Console under *Name ID Format*.
 
 *Name ID Format*:: The Name ID Format for the subject. This format is used if no name ID policy is specified in a request, or if the Force Name ID Format attribute is set to ON.
 
 *Root URL*:: When {project_name} uses a configured relative URL, this value is prepended to the URL.
 
-*Valid Redirect URIs*:: Enter a URL pattern and click the + sign to add.  Click the - sign to remove. Click the *Save* button to save these changes.
+*Valid Redirect URIs*:: Enter a URL pattern and click the + sign to add.  Click the - sign to remove. Click *Save* to save these changes.
 Wildcards values are allowed only at the end of a URL. For example, http://host.com/*$$.
 This field is used when the exact SAML endpoints are not registered and {project_name} pulls the Assertion Consumer URL from a request.
 

server_admin/topics/clients/saml/proc-using-an-entity-descriptor.adoc

@@ -10,7 +10,7 @@ The Add Client page includes an *Import* option.
 image:{project_images}/add-client-saml.png[]
 
 .Procedure
-. Click the *Select File* button.
+. Click *Select File*.
 . Load the file that contains the XML entity descriptor information.  
 . Review the information to ensure everything is set up correctly.
 

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

@@ -57,4 +57,4 @@ but the Facebook Developer Console requires both of them to be filled.
 You will need also to obtain the App ID and App Secret from this page so you can enter them into the {project_name} `Add identity provider` page.
 To obtain this click on `Show` under `App Secret`. Go back to {project_name} and specify those items and finally save your Instagram Identity Provider.
 
-After this it is necessary to make the Instagram app public. Click `App Review` left menu item and then `Requests`. After that follow the instructions on screen.
+Now you can make the Instagram app public. Click `App Review` left menu item and then `Requests`. After that follow the instructions on screen.

server_admin/topics/roles-groups/con-default-roles.adoc

@@ -3,9 +3,9 @@
 [[_default_roles]]
 ==== Default Roles
 [role="_abstract"]
-Default roles allow you to automatically assign user role mappings when any user is newly created or imported through
+Use default roles to automatically assign user role mappings when any user is newly created or imported through
 <<_identity_broker, Identity Brokering>>.
-To specify default roles go to the *Roles* left menu item, and click the *Default Roles* tab.
+To specify default roles, click *Roles* in the menu and click the *Default Roles* tab.
 
 .Default Roles
 image:{project_images}/default-roles.png[]

server_admin/topics/roles-groups/con-role-scope-mappings.adoc

@@ -13,7 +13,7 @@ By default, each client gets all the role mappings of the user. You can view the
 .Full Scope
 image:{project_images}/full-client-scope.png[]
 
-By default, the effective roles of scopes are every declared role in the realm. To change this default behavior, set the *Full Scope Allowed* switch to ON and declare the specific roles you want in each client.  You can also use <<_client_scopes, client scopes>> to define the same role scope mappings for a set of clients.
+By default, the effective roles of scopes are every declared role in the realm. To change this default behavior, toggle *Full Scope Allowed* to ON and declare the specific roles you want in each client.  You can also use <<_client_scopes, client scopes>> to define the same role scope mappings for a set of clients.
 
 .Partial Scope
 image:{project_images}/client-scope.png[]

server_admin/topics/roles-groups/proc-assigning-role-mappings.adoc

@@ -5,7 +5,7 @@
 You can assign User role mappings to a user through the *Role Mappings* tab for that user.
 
 .Procedure
-. Click *Users* in the left menu.
+. 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 the *Role Mappings* tab.
 . Click the role you want to assign to the user in the *Available Roles* box.

server_admin/topics/roles-groups/proc-converting-composite-roles.adoc

@@ -8,7 +8,7 @@ Any realm or client level role can be a _composite role_. A _composite role_ is
 
 To convert a role to a composite role:
 
-. Click *Roles* in the left menu.
+. Click *Roles* in the menu.
 . Click the role to access the roles detail page.
 . Set *Composite Roles* to ON.
 

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

@@ -2,7 +2,7 @@
 
 === Realm Roles
 [role="_abstract"]
-Realm-level roles are a namespace for defining your roles. To see the list of roles, click *Roles* in the left menu.
+Realm-level roles are a namespace for defining your roles. To see the list of roles, click *Roles* in the menu.
 
 image:{project_images}/roles.png[]
 

server_admin/topics/roles-groups/proc-managing-groups.adoc

@@ -3,7 +3,7 @@
 [role="_abstract"]
 Groups in {project_name} manage a common set of attributes and role mappings for each user. Users can be members of any number of groups and inherit the attributes and role mappings assigned to each group.
 
-To manage groups, click *Groups* in the left menu.
+To manage groups, click *Groups* in the menu.
 
 .Groups
 image:{project_images}/groups.png[]
@@ -29,7 +29,7 @@ Attributes and role mappings you define are inherited by the groups and users th
 
 To add a user to a group:
 
-. Click *Users* in the left menu.
+. 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*.
 +

server_admin/topics/roles-groups/proc-specifying-default-groups.adoc

@@ -6,7 +6,7 @@ To automatically assign group membership to new users, that are created or impor
 
 To specify default groups:
 
-. Click *Groups* in the left menu.
+. Click *Groups* in the menu.
 . Click the *Default Groups* tab.
 
 .Default Groups