directory-commits mailing list archives

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

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:08:59 2017
@@ -1 +1 @@
-1794240
+1794242

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:08:59
2017
@@ -178,15 +178,13 @@ h2:hover > .headerlink, h3:hover > .head
 <p>Basically, the idea is, I wanted to have a framework where the developer doesn't
need to programmatically make authorization calls, use annotation or any other kind of “if
condition” statements, in their code. With this solution, I'm can have a declarative
mechanism capable of dynamic authorization decisions, even if the user hasn't been logged
in or has the the proper role activated.  This is because the authorization has been centralized
at the server and that server can activate and deactivate user roles that are needed to access
the runtime environment.</p>
 <p>I searched across all available open source solutions and finally decided to use
Apereo CAS and Apache Fortress as the combined solution. Apereo CAS does the authentication
and Apache Fortress will handle the authorization.</p>
 <p>Apereo CAS is very good way to handle the Single Sign-On and Single Sign-Out problems,
on the other hand Apereo CAS lacks authorization capaibilities because there are no standardized
solutions for the 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 can be combined and create a good solution because they complement
each other.  Unfortunately, there isn't a good documentation resource available to combine
both solution into wone which is why I needed to create this to other developers on my team
and make their life easier.</p>
-<p>With this solution, I have successfully run inside a production environment since
2015 and have maintained this solution for almost 2 years now, I write this documentation
to describe how it works and how you can try something like this as well.</p>
-<p>Here are the technologies stack 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>This solution I present to you here, has operated successfully inside a production
environment since 2015 and so we have maintained it for almost 2 years now, I write this documentation
to describe how it works and so it's something you could 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>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>
@@ -195,7 +193,7 @@ h2:hover > .headerlink, h3:hover > .head
 <h2 id="code-descriptions">Code Descriptions<a class="headerlink" href="#code-descriptions"
title="Permanent link">&para;</a></h2>
 <p>The following sections contain code and xml snippets describing how the CAS and
Fortress integration was accomplished.</p>
 <h3 id="server-side-development">Server side development:<a class="headerlink" href="#server-side-development"
title="Permanent link">&para;</a></h3>
-<h4 id="the-authentication-handler">The Authentication Handler<a class="headerlink"
href="#the-authentication-handler" title="Permanent link">&para;</a></h4>
+<h4 id="1-the-authentication-handler">1. The Authentication Handler<a class="headerlink"
href="#1-the-authentication-handler" title="Permanent link">&para;</a></h4>
 <p>The interesting part for this solution is how to maintain both the Apereo CAS and
Apache Fortress sessions. Luckily, CAS is using a token for maintaining their session and
that token is also designed to have some extended attributes included with it.  Using this
knowledge, we can modify the profile given by CAS Server to the client. Let's have a look
what I've done with combining the Apereo CAS and Apache Fortress sessions in the code that
follows.</p>
 <div class="codehilite"><pre><span class="cm">/*</span>
 <span class="cm"> * Copyright 2017 to PT. Global Digital Niaga(Blibli.com)</span>
@@ -299,7 +297,7 @@ h2:hover > .headerlink, h3:hover > .head
 
 
 <p>In the above source code you can see how I construct a new principal by creating
a new attribute map with values contained withing the Apache Fortress Session xml.</p>
-<h4 id="attribute-populator">Attribute Populator<a class="headerlink" href="#attribute-populator"
title="Permanent link">&para;</a></h4>
+<h4 id="2-the-attribute-populator">2. The Attribute Populator<a class="headerlink"
href="#2-the-attribute-populator" title="Permanent link">&para;</a></h4>
 <p>In order to populate fortress and pass it on to the client we need to override the
casServiceValidationSuccess.jsp file, located at WEB-INF/view/jsp/protocol/2.0/, since its
default view won't populating the necessary attributes. Here is how I was able to accomplish
that:</p>
 <div class="codehilite"><pre><span class="err">&lt;</span>%@
page session=&quot;false&quot; contentType=&quot;application/xml; charset=UTF-8&quot;
%&gt;
 <span class="err">&lt;</span>%@ taglib prefix=&quot;c&quot; uri=&quot;http://java.sun.com/jsp/jstl/core&quot;
%&gt;
@@ -331,10 +329,10 @@ h2:hover > .headerlink, h3:hover > .head
 
 
 <p>One thing that I love about CAS, even if you correctly extracted the attribute at
this page (or maybe you just got hacked at this page), CAS is able to protect the returned
attributes by changing the services registry configuration. see the HTTPSandIMAPS-10000001.json
file. I’ve put ReturnAllAttributeReleasePolicy type for debuging all the attributes returned,
you can change it later to make your application more secure as well.</p>
-<h4 id="apache-ignite-for-ticket-replication">Apache Ignite For Ticket Replication<a
class="headerlink" href="#apache-ignite-for-ticket-replication" title="Permanent link">&para;</a></h4>
+<h4 id="3-apache-ignite-for-ticket-replication">3. Apache Ignite For Ticket Replication<a
class="headerlink" href="#3-apache-ignite-for-ticket-replication" title="Permanent link">&para;</a></h4>
 <p>To have a production readiness we need to somehow manage a high availability requirement,
so we're not just using a single cas server. That is why we needed to have a centralized or
distributed ticket repository, to allow cas to scale. To scale the ticket repository, I chose
Apache Ignite for distributing the tickets. To Implement is very simple, and is also written
about in Apereo CAS documentation.</p>
 <h3 id="client-side-development">Client side development:<a class="headerlink" href="#client-side-development"
title="Permanent link">&para;</a></h3>
-<h4 id="the-spring-voter">The Spring Voter<a class="headerlink" href="#the-spring-voter"
title="Permanent link">&para;</a></h4>
+<h4 id="1-the-spring-voter">1. The Spring Voter<a class="headerlink" href="#1-the-spring-voter"
title="Permanent link">&para;</a></h4>
 <p>Spring is a great framework, they allow you to add your own interceptors to use
your own implementation. WebExpressionVoter is the class you need to extend in order to override
the normal spring decision mechanism.  Usually you will use xml + regex for registering the
condition. However, xml + regex is not the approach I wanted for my development team. See
below code snippet, to understand what I did to make this more dynamic.</p>
 <div class="codehilite"><pre>  <span class="nd">@Override</span>
   <span class="nd">@SuppressWarnings</span><span class="o">(</span><span
class="s">&quot;static-access&quot;</span><span class="o">)</span>
@@ -398,7 +396,7 @@ h2:hover > .headerlink, h3:hover > .head
 
 
 <p>Yep, I'm calling fortress to check if the user is allowed to access fortress permissions
or not.</p>
-<h5 id="userdetail-populator">UserDetail Populator<a class="headerlink" href="#userdetail-populator"
title="Permanent link">&para;</a></h5>
+<h5 id="2-userdetail-populator">2. UserDetail Populator<a class="headerlink" href="#2-userdetail-populator"
title="Permanent link">&para;</a></h5>
 <p>Spring uses the implementation of AbstractCasAssertionUserDetailsService to populate
user details following successful authentication, you can see the example at IamUserDetails
code, here is the snipet of that class:</p>
 <div class="codehilite"><pre><span class="nd">@Override</span>
   <span class="kd">protected</span> <span class="n">UserDetails</span>
<span class="nf">loadUserDetails</span><span class="o">(</span><span
class="kd">final</span> <span class="n">Assertion</span> <span class="n">assertion</span><span
class="o">)</span> <span class="o">{</span>
@@ -439,7 +437,7 @@ h2:hover > .headerlink, h3:hover > .head
 
 
 <p>You can change the implementation later for your needs.</p>
-<h5 id="network-might-be-a-problem">Network Might Be a Problem<a class="headerlink"
href="#network-might-be-a-problem" title="Permanent link">&para;</a></h5>
+<h5 id="3-network-might-be-a-problem">3. Network Might Be a Problem<a class="headerlink"
href="#3-network-might-be-a-problem" title="Permanent link">&para;</a></h5>
 <p>Since this is running inside a production environment, we needed to consider that
sometimes there might be a trouble over our network that causes problems and requires retries.
That is why it's important to allow a little delay time in our application.  Here's an example
of how allow a small delay, in order to allow temorary network glitches and slowdowns to work
themselves out.</p>
 <div class="codehilite"><pre><span class="cm">/*</span>
 <span class="cm"> * Copyright 2017 to PT. Global Digital Niaga(Blibli.com)</span>



Mime
View raw message