Fixes for the typos found

topics/MigrationFromOlderVersions.adoc

@@ -156,7 +156,7 @@ See documentation for more details if you want to catch and handle adapter error
 ===== IdentityProviderMapper changes
 
 There is no change in the interface itself or method signatures.
-However there is some change in behaviour.
+However there is some change in behavior.
 We added `First Broker Login` flow in this release and the method `IdentityProviderMapper.importNewUser` is now called after `First Broker Login` flow is finished.
 So if you want to have any attribute available in `Review Profile` page, you would need to use the method `preprocessFederatedIdentity` instead of `importNewUser` . You can set any attribute by invoke `BrokeredIdentityContext.setUserAttribute` and that will be available on `Review profile` page. 
 

topics/overview.adoc

@@ -4,7 +4,7 @@
 is make security simple so that it is easy for application developers to secure the apps and services they have deployed
 in their organization.  Security features that developers normally have to write for themselves are provided out of the box
 and are easily tailorable to the individual requirements of your organization.  {{book.project.name}} provides customizable
-user interfaces for login, registration, adminstration, and account management.  You can also use {{book.project.name}} as an
+user interfaces for login, registration, administration, and account management.  You can also use {{book.project.name}} as an
 integration platform to hook it into existing LDAP and Active Directory servers.  You can also delegate authentication to third
 party identity providers like Facebook and Google+.  {{book.project.name}} has tons of SPIs that you can use to customize every
 aspect of the server.

topics/sso-protocols/oidc.adoc

@@ -5,17 +5,17 @@
 link:http://openid.net/connect/[Open ID Connect] (OIDC) is an authentication protocol that is an extension of link:https://tools.ietf.org/html/rfc6749[OAuth 2.0].
 While OAuth 2.0 is only a framework for building authorization protocols and is mainly incomplete, OIDC is a full-fledged authentication and authorization
 protocol.  OIDC also makes heavy use of the link:https://jwt.io[Json Web Token] (JWT) set of standards.  These standards define a
-identity token JSON format and ways to digitially sign and encrypt that data in a compact and web-friendly way.
+identity token JSON format and ways to digitally sign and encrypt that data in a compact and web-friendly way.
 
 There is really two types of use cases when using OIDC.  The first is an application that asks the {{book.project.name}} server to authenticate
 a user for them.  After a successful login, the application will receive an _identity token_ and an _access token_.  The _identity token_
-contains information about the user such as username, email, and other profile information.  The _access token_ is digitially signed by
+contains information about the user such as username, email, and other profile information.  The _access token_ is digitally signed by
 the realm and contains access information (like user role mappings) that the application can use to determine what resources the user
 is allowed to access on the application.
 
 The second type of use cases is that of a client that wants to gain access to remote services.  In this case, the client asks {{book.project.name}}
 to obtain an _access token_ it can use to invoke on other remote services on behalf of the user.  {{book.project.name}} authenticates the user
-then asks the user for consent to grant access to the client requesting it.  The clien then receives the _access token_.  This _access token_
+then asks the user for consent to grant access to the client requesting it.  The client then receives the _access token_.  This _access token_
 is digitally signed by the realm.  The client can make REST invocations on remote services using this _access token_.  The REST service
 extracts the _access token_, verifies the signature of the token, then decides based on access information within the token whether or not to process
 the request.
@@ -31,7 +31,7 @@ OIDC and OAuth 2.0 specifications so only a brief overview will be provided here
 ===== Authorization Code Flow
 
 This is a browser-based protocol and what we recommend you use to authenticate and authorize browser-based applications.  It makes
-heavy use of browser redirects to obtain an _identiy_ and _access_ token.  Here's a brief summary
+heavy use of browser redirects to obtain an _identity_ and _access_ token.  Here's a brief summary
 
 . Browser visits application.  The application notices the user is not logged in, so it redirects the browser to {{book.project.name}}
   to be authenticated.  The application passes along a callback URL (a redirect URL) as a query parameter in this browser redirect
@@ -62,7 +62,7 @@ into this in the
 ===== Implicit Flow
 
 This is a browser-based protocol that is similar to Authorization Code Flow except there are fewer requests and no refresh tokens involved.
-We do not recommend this flow as there remains the possiblity of _access_ tokens being leaked in the browser history as tokens are transmitted
+We do not recommend this flow as there remains the possibility of _access_ tokens being leaked in the browser history as tokens are transmitted
 via redirect URIs (see below).  Also, since this flow doesn't provide the client with a refresh token, access tokens would either have to
 be long-lived or users would have to re-authenticate when they expired.  This flow is supported because its in the OIDC and OAuth 2.0 specification.
 Here's a brief summary of the protocol:
@@ -71,7 +71,7 @@ Here's a brief summary of the protocol:
   to be authenticated.  The application passes along a callback URL (a redirect URL) as a query parameter in this browser redirect
   that {{book.project.name}} will use when it finishes authentication.
 . {{book.project.name}} authenticates the user and creates an _identity_ and _access_ token.  {{book.project.name}}
-  redirects back to the appliciation using the callback URL provided earlier and additionally adding the _identity_ and
+  redirects back to the application using the callback URL provided earlier and additionally adding the _identity_ and
   _access_ tokens as query parameters in the callback URL.
 . The application extracts the the _identity_ and _access_ tokens from the callback URL.
 

topics/sso-protocols/saml.adoc

@@ -11,7 +11,7 @@ In {{book.project.name}} SAML serves two types of use cases: browser application
 
 There is really two types of use cases when using SAML.  The first is an application that asks the {{book.project.name}} server to authenticate
 a user for them.  After a successful login, the application will receive an XML document that contains
-something called a SAML assertion that specify various attributes about the user.  THis XML document is digitially signed by
+something called a SAML assertion that specify various attributes about the user.  THis XML document is digitally signed by
 the realm and contains access information (like user role mappings) that the application can use to determine what resources the user
 is allowed to access on the application.
 
@@ -38,7 +38,7 @@ how it works.
   the digital signature if required.  The user then has to enter in their credentials to be authenticated
 . After authentication, the server generates an XML authentication response document.  This document contains
   a SAML assertion that holds metadata about the user like name, address, email, and also an role mappings the user
-  might have.  This document is almost always digitially signed and using XML signatures, and may also be encrypted.
+  might have.  This document is almost always digitally signed and using XML signatures, and may also be encrypted.
 . The XML auth response document is then encoded as a query param in a redirect URI that brings the browser back
   to the application.  The digital signature is also included as a query param.
 . The application receives the redirect URI and extracts the XML document and verifies the realm's signature to make
@@ -48,9 +48,9 @@ how it works.
 ===== POST Binding
 
 The SAML _POST_ binding works almost the exact same way as the _Redirect_ Binding, but instead of GET requests, XML
-documents are exchanged by POST requests.  The _POST_ Binding uses Javascript to trick the browser into making a POST request to
-the {{book.project.name}} server or application when exchanging documents.  Bascially HTTP responses contain an HTML document
-that contains an HTML form with embedded Javascript.  When the page is loaded, the Javascript automatically invokes the form.
+documents are exchanged by POST requests.  The _POST_ Binding uses JavaScript to trick the browser into making a POST request to
+the {{book.project.name}} server or application when exchanging documents.  Basically HTTP responses contain an HTML document
+that contains an HTML form with embedded JavaScript.  When the page is loaded, the JavaScript automatically invokes the form.
 You really don't need to know about this stuff, but it is a pretty clever trick.
 
 ===== ECP

topics/threat/brute-force.adoc

@@ -13,12 +13,12 @@ image:../../{{book.images}}/brute-force.png[]
 The way this works is that if there are `Max Login Failures` during a period of `Failure Reset Time`,
 the account is temporarily disabled for the `Wait Increment` multiplied by the number of failures over the max.  After
 `Failure Reset Time` is reached all failures are wiped clean.  The `Max Wait` is the maximum amount of time
-an account can be disabled for.  Another preventitive measure is that if there is subsequent login failures for one
+an account can be disabled for.  Another preventive measure is that if there is subsequent login failures for one
 account that are too quick for a human to initiate the account will be disabled then.  This is controlled by the
 `Quick Login Check Milli Seconds` value.  So, if there are two login failures for the same account within that value,
 the account will be disabled for `Minimum Quick Login Wait`.
 
-The downside of {{book.project.name}} brute force detection is that the server becomes vulnerble to denial of service attacks.
+The downside of {{book.project.name}} brute force detection is that the server becomes vulnerable to denial of service attacks.
 An attacker can simply try to guess passwords for as many accounts it knows and these account will be disabled.  Eventually
 Eventually we will expand this functionality to take client IP address into account when deciding whether to block a user.
 

topics/threat/csrf.adoc

@@ -8,8 +8,8 @@ These attacks are mitigated by matching a state cookie against a posted form or
 OAuth 2.0 login specification requires that a state cookie be used and matched against a transmitted state parameter.
 {{book.project.name}} fully implements this part of the specification so all logins are protected.
 
-The {{book.project.name}} Adin Consnole is a pure Javascript/HTML5 application that makes REST calls to the backend {{book.project.name}} admin REST API.
-These calls all require bearer token authentication and are made via Javascript Ajax calls.
+The {{book.project.name}} Adin Console is a pure Javascript/HTML5 application that makes REST calls to the backend {{book.project.name}} admin REST API.
+These calls all require bearer token authentication and are made via JavaScript Ajax calls.
 CSRF does not apply here.
 The admin REST API can also be configured to validate the CORS origins as well.
 

topics/user-federation/ldap.adoc

@@ -70,11 +70,11 @@ if the connection to LDAP starts with `ldaps`.
 LDAP Federation Provider will automatically take care of synchronization (import) of needed LDAP users into the {{book.project.name}} local database.
 As users log in, the LDAP Federation provider will import the LDAP user
 into then {{book.project.name}} database and then authenticate against the LDAP password. This is the only time users will be imported.
-If you go to the `Users` left menu item in the Admin Consoel and click the `View all users` button, you will only see those LDAP users that
+If you go to the `Users` left menu item in the Admin Console and click the `View all users` button, you will only see those LDAP users that
 have been authenticated at least once by {{book.project.name}}.  It is implemented this way so that admins don't accidentally try and import a huge LDAP DB of users.
 
 If you want to sync all LDAP users into the {{book.project.name}} database, you may configure and enable the `Sync Settings` of the LDAP provider you configured.
-There are 2 types of sychronization:
+There are 2 types of synchronization:
 
 Periodic Full sync::
   This will synchronize all LDAP users into {{book.project.name}} DB.
@@ -82,9 +82,9 @@ Periodic Full sync::
   (For example if user `Mary Kelly` was changed in LDAP to `Mary Smith`).
 
 Periodic Changed users sync::
-  When synching occurs, only those users that were created or updated after the last sync will be updated and/or imported.
+  When syncing occurs, only those users that were created or updated after the last sync will be updated and/or imported.
 
-The best way to handle synching is to click the `Synchronize all users` button when you first create the LDAP provider,
+The best way to handle syncing is to click the `Synchronize all users` button when you first create the LDAP provider,
 then set up a periodic sync of changed users.  The configuration page for your LDAP Provider has a bunch of options to support you here.
 
 [[_ldap_mappers]]
@@ -101,7 +101,7 @@ User Attribute Mapper::
   For this mapper implementation, there is always one-to-one mapping (one LDAP attribute is mapped to one {{book.project.name}} attribute)
 
 FullName Mapper::
-  This allows to specify that the fullname of user, which is saved in some LDAP attribute (usualy `cn` ) will be mapped to `firstName` and `lastname` attributes in the {{book.project.name}} database.
+  This allows to specify that the full name of user, which is saved in some LDAP attribute (usually `cn` ) will be mapped to `firstName` and `lastname` attributes in the {{book.project.name}} database.
   Having `cn` to contain full name of user is common case for some LDAP deployments. 
 
 Role Mapper::