Merge pull request #65 from ccopelloRH/Beta

Last RHSSO602 updates

.gitignore

@@ -27,7 +27,7 @@ catalog.xml
 # Packages #
 ############
 # it's better to unpack these files and commit the raw source
-# git has its own built in compression methods
+# git has its own built-in compression methods
 *.7z
 *.dmg
 *.gz

topics/MigrationFromOlderVersions.adoc

@@ -335,7 +335,7 @@ In order to add more compliance with OpenID Connect specification, we added flag
 Clients migrated from previous version have `Direct Access Grants` enabled just if they had flag `Direct Grants Only` on.
 The `Direct Grants Only` flag was removed as if you enable Direct Access Grants and disable both Standard+Implicit flow, you will achieve same effect.
 
-We also added builtin client `admin-cli` to each realm.
+We also added built-in client `admin-cli` to each realm.
 This client has `Direct Access Grants` enabled.
 So if you're using Admin REST API or Keycloak admin-client, you should update your configuration to use `admin-cli` instead of `security-admin-console` as the latter one doesn't have direct access grants enabled anymore by default.
 

topics/account.adoc

@@ -2,7 +2,7 @@
 
 == User Account Service
 
-{{book.project.name}} has a built in User Account Service which every user has access to.  This service allows users to manage their account,
+{{book.project.name}} has a built-in User Account Service which every user has access to.  This service allows users to manage their account,
 change their credentials, update their profile, and view their login sessions.  The URL to this service is `<server-root>/auth/realms/\{realm-name}/account`.
 
 .Account Service

topics/authentication.adoc

@@ -4,4 +4,4 @@
 There are a few features you should be aware of when configuring authentication for your realm.  Many organizations
 have strict password and OTP policies that you can enforce via settings in the Admin Console.  You may or may not
 want to require different credential types for authentication.  You may want to give users the option to login via
-Kerberos or disable or enable various built in credential types.  This chapter covers all of these topics.
+Kerberos or disable or enable various built-in credential types.  This chapter covers all of these topics.

topics/authentication/kerberos.adoc

@@ -107,7 +107,7 @@ Turning on the switch `Allow Kerberos authentication` will make {{book.project.n
 be imported into the {{book.project.name}} environment.
 
 If your Kerberos solution is not backed by an LDAP server, you have to use the `Kerberos` User Storage Federation Provider.  Go to the `User Federation`
-left menu item and select `Kerberos` from the right `Add provider` select box.
+left menu item and select `Kerberos` from the `Add provider` select box.
 
 .Kerberos User Storage Provider
 image:../../{{book.images}}/kerberos-provider.png[]

topics/clients/oidc/service-accounts.adoc

@@ -2,7 +2,7 @@
 
 === Service Accounts
 
-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_ which allows it to obtain an access token.
 This is covered in the OAuth 2.0 specifiation under <<fake/../../../sso-protocols/oidc.adoc#_client_credentials_grant,Client Credentials Grant>>.
 To use this feature you must set the <<fake/../../../clients/client-oidc.adoc#_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

topics/events.adoc

@@ -3,6 +3,5 @@
 
 {{book.project.name}} provides a rich set of auditing capabilities.  Every single login action can be recorded and stored in
 the database and reviewed in the Admin Console.  All admin actions can also be recorded and reviewed.  There is also a Listener SPI
-with which plugins can listen for these events and perform some action.  Built in listeners include a simple log file and the ability
+with which plugins can listen for these events and perform some action.  Built-in listeners include a simple log file and the ability
 to send an email if an event occurs.
-

topics/events/login.adoc

@@ -60,7 +60,7 @@ For all events there is a corresponding error event.
 
 ==== Event Listener
 
-Event listeners listen for events and perform an action based on that event.  There are two built in
+Event listeners listen for events and perform an action based on that event.  There are two built-in
 listeners that come with {{book.project.name}}: Logging Event Listener and Email Event Listener.
 
 The Logging Event Listener writes to a log file whenever an error event occurs and is enabled by default.
@@ -106,6 +106,3 @@ that comes with your distribution and adding for example:
 
 See the link:{{book.installguide.link}}[{{book.installguide.name}}] for more details on
 where the `standalone.xml`, `standalone-ha.xml`, or `domain.xml` file lives.
-
-
-

topics/login-settings.adoc

@@ -1,4 +1,4 @@
 
 == Login Page Settings
 
-There are several nice built in login page features you can enable if you need the functionality.
+There are several nice built-in login page features you can enable if you need the functionality.

topics/overview/concepts.adoc

@@ -56,7 +56,7 @@ assertion::
   Information about a user.  This usually pertains to an XML blob that is included in a SAML authentication response that
   provided identity metadata about an authenticated user.
 service account::
-  Each client has a built in service account which allows it to obtain an access token.
+  Each client has a built-in service account which allows it to obtain an access token.
 direct grant::
   A way for a client to obtain an access token on behalf of a user via a REST invocation.
 protocol mappers::

topics/user-federation/ldap.adoc

@@ -91,7 +91,7 @@ then set up a periodic sync of changed users.  The configuration page for your L
 
 LDAP mappers are `listeners`, which are triggered by the LDAP Federation provider at various points, provide another extension point to LDAP integration.
 They are triggered when a user logs in via LDAP and needs to be imported, during {{book.project.name}} initiated registration, or when a user is queried from the Admin Console.
-When you create an LDAP Federation provider, {{book.project.name}} will automatically provide set of builtin `mappers` for this provider.
+When you create an LDAP Federation provider, {{book.project.name}} will automatically provide set of built-in `mappers` for this provider.
 You are free to change this set and create a new mapper or update/delete existing ones.
 
 User Attribute Mapper::
@@ -130,4 +130,3 @@ MSAD User Account Mapper::
 By default, there is set of User Attribute mappers that map basic {{book.project.name}} user attributes like username, first name, lastname, and email to corresponding LDAP attributes.
 You are free to extend these and provide additional attribute mappings.
 Admin console provides tooltips, which should help with configuring the corresponding mappers.
-

topics/users/credentials.adoc

@@ -14,7 +14,7 @@ If the `Temporary` switch is on, this new password can only be used once and the
 logged in.
 
 Alternatively, if you have <<fake/../../realms/email.adoc#_email, email>> set up, you can send an email to the user that asks
-them to reset their password.  Choose `Update Password` from the `Reset Actions` list box and click the `Send Email`.
+them to reset their password.  Choose `Update Password` from the `Reset Actions` list box and click `Send Email`.
 The sent email contains a link that will bring the user to the update password screen.
 
 ==== Changing OTPs

topics/users/required-actions.adoc

@@ -3,7 +3,7 @@
 
 Required Actions are tasks that a user must finish before they are allowed to log in.  A user must provide their credentials before required actions are executed.  Once a required action is completed, the user will not have
 to perform the action again.
-Here are an explanation of some of the built in required action types:
+Here are an explanation of some of the built-in required action types:
 
 Update Password::
    When set, a user must change their password.