Doc updates

cas-server-documentation/installation/Configuring-Service-Access-Strategy.md

@@ -65,7 +65,7 @@ The `GrouperRegisteredServiceAccessStrategy` is enabled by including the followi
 ```
 
 This access strategy attempts to locate [Grouper](https://www.internet2.edu/products-services/trust-identity-middleware/grouper/) groups for the CAS principal. The groups returned by Grouper
-are collected as CAS attribtues and examined against the list of required attributes for service access.
+are collected as CAS attributes and examined against the list of required attributes for service access.
 
 The following properties are available:
 

cas-server-documentation/installation/Logout-Single-Signout.md

@@ -16,7 +16,7 @@ Note that the logout action in each case has no effect on the other in the simpl
 does not end the CAS session and ending the CAS session does not affect application sessions. This is a common cause of
 confusion for new users and deployers of an SSO system.
 
-The single logout support in CAS attempts to reconcile the dispartity between CAS logout and application logout. When
+The single logout support in CAS attempts to reconcile the disparity between CAS logout and application logout. When
 CAS is configured for SLO, it attempts to send logout messages to every application that requested authentication to
 CAS during the SSO session. While this is a best-effort process, in many cases it works well and provides a consistent
 user experience by creating symmetry between login and logout.
@@ -80,7 +80,11 @@ To disable single logout, adjust the following setting in `application.propertie
 ```
 
 ### Single Logout Per Service
-Registered applications with CAS have the option to control single logout behavior individually via the [Service Managament](Service-Management.html) component. Each registered service in the service registry will include configuration that describes how to the logout request should be submitted. This behavior is controlled via the `logoutType` property which allows to specify whether the logout request should be submitted via back/front channel or turned off for this application.
+
+Registered applications with CAS have the option to control single logout behavior individually via
+the [Service Management](Service-Management.html) component. Each registered service in the service registry will include configuration 
+that describes how to the logout request should be submitted. This behavior is controlled via the `logoutType` property 
+which allows to specify whether the logout request should be submitted via back/front channel or turned off for this application.
 
 Sample configuration follows:
 
@@ -112,8 +116,9 @@ To configure a service specific endpoint, try the following example:
 }
 ```
 
-### Aynchronous SLO Messages
-By default, backchannel logout messages are sent to endpoint in an asynchronous fashion. To allow synchronous messages, modify the following setting in `application.properties`:
+### Asynchronous SLO Messages
+By default, backchannel logout messages are sent to endpoint in an asynchronous fashion. To allow synchronous messages, 
+modify the following setting in `application.properties`:
 
 ```bash
 # To send callbacks to endpoints synchronously, set this to false

cas-server-documentation/installation/SPNEGO-Authentication.md

@@ -23,7 +23,7 @@ ticket expires.
 ## Requirements
 
 * Client is logged in to a Windows Active Directory domain.
-* Supported browser and JDK.
+* Supported browser.
 * CAS is running MIT kerberos against the AD domain controller.
 
 ## Components

cas-server-documentation/installation/Troubleshooting-Guide.md

@@ -21,7 +21,8 @@ You may encounter this error, when the requesting application/service url cannot
 Please [review this guide](Service-Management.html) to better understand the CAS service registry.
 
 ## Invalid/Expired CAS Tickets
-You may experience `INVAILD_TICKET` related errors when attempting to use a CAS ticet whose expiration policy dictates that the ticket has expired. The CAS log should further explain in more detail if the ticket is considered expired, but for diagnostic purposes, you may want to adjust the [ticket expiration policy configuration](Configuring-Ticket-Expiration-Policy.html) to remove and troubleshoot this error.
+You may experience `INVAILD_TICKET` related errors when attempting to use a CAS ticket whose expiration policy dictates that the ticket 
+has expired. The CAS log should further explain in more detail if the ticket is considered expired, but for diagnostic purposes, you may want to adjust the [ticket expiration policy configuration](Configuring-Ticket-Expiration-Policy.html) to remove and troubleshoot this error.
 
 Furthermore, if the ticket itself cannot be located in the CAS ticket registry the ticket is also considered invalid. You will need to observe the ticket used and compare it with the value that exists in the ticket registry to ensure that the ticket id provided is valid.  
 

cas-server-documentation/installation/Webflow-Customization-Sessions.md

@@ -39,7 +39,7 @@ To see the relevant list of CAS properties, please [review this guide](Configura
 
 Doing so will likely require you to also enable sticky sessions and/or session replication in a clustered deployment of CAS.
 
-### Hazelast Session Replication
+### Hazelcast Session Replication
 
 If you don't wish to use the native container's strategy for session replication, 
 you can use CAS's support for Hazelcast session replication.

cas-server-documentation/integration/Attribute-Resolution.md

@@ -108,7 +108,7 @@ The module provides a `shibbolethPersonAttributeDao` that the Shibboleth's `attr
 
 - Modify either `application.properties` or the runtime environment 
 to reference the `attribute-resolver.xml` resource via a property. This is a
-comma seperated list of resources to use for the configuration:
+comma separated list of resources to use for the configuration:
 
 ```shell
 -Dcas.shibAttributeResolver.resources=classpath:attribute-resolver.xml

cas-server-documentation/planning/Architecture.md

@@ -87,7 +87,7 @@ CAS uses the many aspects of the Spring Framework; most notably,
 [Spring Webflow](http://www.springsource.org/spring-web-flow). Spring provides a complete and extensible framework for
 the core CAS codebase as well as for deployers; it's straightforward to customize or extend CAS behavior by hooking
 CAS and Spring API extension points. General knowledge of Spring is beneficial to understanding the interplay among
-some framework compoents, but it's not strictly required. The XML-based configuration used to configure CAS and Spring
+some framework components, but it's not strictly required. The XML-based configuration used to configure CAS and Spring
 components, however, is a core concern for installation, customization, and extension. Competence with XML generally
 and the
 [Spring IOC Container](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html)