directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1011814 - in /websites/staging/directory/trunk/content: ./ fortress/testimonials.html
Date Sun, 07 May 2017 18:22:13 GMT
Author: buildbot
Date: Sun May  7 18:22:13 2017
New Revision: 1011814

Log:
Staging update by buildbot for directory

Modified:
    websites/staging/directory/trunk/content/   (props changed)
    websites/staging/directory/trunk/content/fortress/testimonials.html

Propchange: websites/staging/directory/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sun May  7 18:22:13 2017
@@ -1 +1 @@
-1794249
+1794254

Modified: websites/staging/directory/trunk/content/fortress/testimonials.html
==============================================================================
--- websites/staging/directory/trunk/content/fortress/testimonials.html (original)
+++ websites/staging/directory/trunk/content/fortress/testimonials.html Sun May  7 18:22:13
2017
@@ -177,14 +177,16 @@ h2:hover > .headerlink, h3:hover > .head
 <p>I created this solution a few years ago because at the time I was looking for an
IAM and SSO solution, and there were no open source solutions that provided everything that
I needed.</p>
 <p>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.</p>
 <p>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.</p>
-<p>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 provding
good security for their webapps.</p>
+<p>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.</p>
 <p>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.</p>
-<p>Here are the technologies stack used within my extended framework:
- * Apereo CAS -&gt; 4.2.x
- * Apache Fortress Enmasse (rest) -&gt; 1.0.0
- * Apache Fortress Proxy -&gt; 1.0.0
- * Apache Ignite -&gt; 1.7.0
- * Spring Framework -&gt; 4.2.x-RELEASE</p>
+<p>Here are the technology stacks used within my extended framework:</p>
+<ul>
+<li>Apereo CAS -&gt; 4.2.x</li>
+<li>Apache Fortress Enmasse (rest) -&gt; 1.0.0</li>
+<li>Apache Fortress Proxy -&gt; 1.0.0</li>
+<li>Apache Ignite -&gt; 1.7.0</li>
+<li>Spring Framework -&gt; 4.2.x-RELEASE</li>
+</ul>
 <p>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:</p>
 <ol>
 <li>CAS Server side development: Includes creating own implementation for AbstractUsernamePasswordAuthenticationHandler
and implemening an Apache Ignite Service Registry for CAS</li>



Mime
View raw message