svn commit: r1794487 - /directory/site/trunk/content/fortress/testimonials.mdtext

[sm...@apache.org]

Author: smckinney
Date: Tue May  9 02:31:42 2017
New Revision: 1794487

URL: http://svn.apache.org/viewvc?rev=1794487&view=rev
Log:
minor

Modified:
    directory/site/trunk/content/fortress/testimonials.mdtext

Modified: directory/site/trunk/content/fortress/testimonials.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/fortress/testimonials.mdtext?rev=1794487&r1=1794486&r2=1794487&view=diff
==============================================================================
--- directory/site/trunk/content/fortress/testimonials.mdtext (original)
+++ directory/site/trunk/content/fortress/testimonials.mdtext Tue May  9 02:31:42 2017
@@ -13,11 +13,11 @@ I created this solution a few years ago
 
 Basically, the idea was, I needed a framework where the developer didn't have to programmatically add authorization calls to their code, or use annotations, or any other kind of “if condition” statement. With this solution, I can have a declarative mechanism that is still capable of making advanced dynamic authorization decisions, even if the user hasn't been logged in before or has any of the proper roles activated to their session.  I can do this because I control the authorization and it has been centralized in the server, and that server can activate whatever user roles needed to to allow access to the runtime environment.
 
-I searched across all available open source solutions and finally decided to combine Apereo CAS and Apache Fortress into a single solution. Apereo CAS does the authentication and Apache Fortress will handle authorization.
+I searched all available open source solutions and finally decided to combine Apereo CAS and Apache Fortress into a single solution. Apereo CAS does the authentication and Apache Fortress will handle authorization.
 
-Apereo CAS is very good way to handle the Single Sign-On and Single Sign-Out problems, on the other hand it lacks authorization capaibilities because there aren't standardized solutions for authorization in that space yet. Apache Fortress is good at authorization because it uses standard RBAC. However, Apache Fortress doesn't have an SSO solution yet. That is why I think both should be combined because they complement each other.  Unfortunately, there aren't yet good documentation resources available to combine these which is why I figured I needed to create this, so other developers can follow my team's lead and make their life easier providing good security for their webapps.
+I went this route because Apereo CAS is very good way to handle the Single Sign-On and Single Sign-Out problems, but it lacks authorization capabilities, because there aren't standardized solutions in that space yet. Apache Fortress is good at authorization because it uses standard RBAC. However, Apache Fortress doesn't have an SSO solution yet. That is why I think both should be combined because they complement each other.  Unfortunately, there aren't yet good documentation resources available to combine these which is why I created this one, so other developers can follow my team's lead and make their life easier by providing good security for their webapps.
 
-The solution I present to you here has operated successfully inside production environments since 2015 and so we have maintained it for almost 2 years now and it's quite mature.  I write this documentation to describe how it works and it's intended as something you should try as well.
+The solution I present to you here has operated successfully inside production environments since 2015 and so have maintained it for almost 2 years now and so it's quite mature.  I write this description of how it works and it's intended as something you should try as well.
 
 Here are the technology stacks used within my extended framework:
 
@@ -27,7 +27,7 @@ Here are the technology stacks used with
  * Apache Ignite -> 1.7.0
  * Spring Framework -> 4.2.x-RELEASE
 
-There are two types of development required, one on server side and other on the client, which is then used by my team for managing security within their own web applications:
+There are two steps of development.  One to handle the server side and the other for the client.  The client is shared across my dev team for managing security within their web applications.
 
  1. CAS Server side development: Includes creating own implementation for AbstractUsernamePasswordAuthenticationHandler and implemening an Apache Ignite Service Registry for CAS
  2. CAS Client side development: Includes create own implementation for WebExpressionVoter and CasAuthenticationProvider