ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r814401 - in /websites/staging/ace/trunk/content: ./ dev-doc/design/ace-authentication.html
Date Wed, 25 Apr 2012 13:31:18 GMT
Author: buildbot
Date: Wed Apr 25 13:31:18 2012
New Revision: 814401

Log:
Staging update by buildbot for ace

Modified:
    websites/staging/ace/trunk/content/   (props changed)
    websites/staging/ace/trunk/content/dev-doc/design/ace-authentication.html

Propchange: websites/staging/ace/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Wed Apr 25 13:31:18 2012
@@ -1 +1 @@
-1330259
+1330279

Modified: websites/staging/ace/trunk/content/dev-doc/design/ace-authentication.html
==============================================================================
--- websites/staging/ace/trunk/content/dev-doc/design/ace-authentication.html (original)
+++ websites/staging/ace/trunk/content/dev-doc/design/ace-authentication.html Wed Apr 25 13:31:18
2012
@@ -155,7 +155,7 @@
       <div id="content"><p><em>Enabling authentication in ACE</em></p>
 <p>last updated: April 25th, 2012</p>
 <h2 id="introduction">Introduction</h2>
-<p>When provisioning software (partly) to targets, one has to rely upon the trustworthiness
of both the network and the target. Even if everything is under your control and governance,
one cannot entirely be sure that unwanted access takes place. A first step in order to prevent
unwanted access is <em>authentication</em>, which gives you the ability to verify
the identity of someone. Once the identity is known, one can apply <em>authentication</em>
in order to determine what actions are allowed and which are not.
+<p>When provisioning software (partly) to targets, one has to rely upon the trustworthiness
of both the network and the target. Even if everything is under your control and governance,
one cannot entirely be sure that unwanted access takes place. A first step in order to prevent
unwanted access is <em>authentication</em>, which gives you the ability to verify
the identity of someone. Once the identity is known, one can apply <em>authorization</em>
in order to determine what actions are allowed and which are not.
 In this article, the recently added authentication layer of ACE is explained in more depth,
and some details on how extensions can be written for additional mechanisms are given. The
remainder of this article assumes the reader has basic knowledge of the principles behind
ACE, and has sufficient programming skills. For this article, the latest code of ACE (0.8.1-SNAPSHOT,
rev.1329269) was used.</p>
 <h2 id="communication-paths">Communication paths</h2>
 <p>Before going in more depth on the authentication layer of ACE, we first need to
pinpoint all places were authentication is to be applied. The following figure shows the main
components in ACE and their communication paths, providing a global overview of where authentication
is applicable to ACE.</p>
@@ -257,11 +257,11 @@ Figure 3: Connection Factory class diagr
 </tr>
 </tbody>
 </table>
-<p>Table 1: Remote services overview. Common prefix of configuration PIDs are abbreviated:
<tt>o.a.a</tt> = <tt>org.apache.ace</tt>.</p>
+<p>Table 1: Remote services overview. Common prefix of configuration PIDs are abbreviated,
so <tt>o.a.a</tt> stands for <tt>org.apache.ace</tt>.</p>
 <h3 id="configuring-authentication-for-remote-services">Configuring authentication
for remote services</h3>
 <p>In the section on the design of the authentication layer, we've mentioned that if
a remote service wants to make use of authentication, it can make use of the <tt>AuthenticationService</tt>.
However, one of the design requirements was that authentication should be optional as well.
In order to enable or disable authentication, each remote service needs to do the following:</p>
 <ol>
-<li>add a <strong>mandatory</strong> configuration property <code>authentication.enabled
= false|true</code> to their configuration. Although any kind of name for this configuration
property can be used, it is <em>strongly</em> advised to stick to the same name
for all services;</li>
+<li>add a <strong>mandatory</strong> configuration property <tt>authentication.enabled
= false|true</tt> to their configuration. Although any kind of name for this configuration
property can be used, it is <em>strongly</em> advised to stick to the same name
for all services;</li>
 <li>when the configuration of a remote service is updated, it should add a service
dependency to the <tt>AuthenticationService</tt>. By making this service <em>required</em>
when authentication is enabled, and <em>optional</em> when authentication is disabled,
we can adhere to the requirement of optionality for authentication;</li>
 <li>in case authentication is <em>enabled</em>, each request the service
obtains needs to be passed to the <tt>AuthenticationService</tt> first, and depending
on its outcome, the request can continue or not.</li>
 </ol>
@@ -353,7 +353,20 @@ Figure 3: Connection Factory class diagr
 
 <p>When this configuration is supplied to the <tt>ConnectionFactory</tt>,
it will provide a basic HTTP authentication header to each connection created for any URL
starting with "<tt>http://localhost:8080/obr/</tt>"<sup id="fnref:6"><a
href="#fn:6" rel="footnote">6</a></sup>. </p>
 <h3 id="configuring-the-management-agent">Configuring the management agent</h3>
+<p>The management agent itself also needs to use authentication to communicate with
the remote services of the ACE server. It reuses the <tt>ConnectionFactory</tt>
service for this, so it needs to obtain the same set of configurations as described in the
previous section. The only thing we need to do is tell the management agent were it can find
those configuration files:</p>
+<div class="codehilite"><pre><span class="o">[</span>localhost:~/<span
class="o">]</span><span class="nv">$ </span>java -jar org.apache.ace.launcher-0.8.1-SNAPSHOT.jar
<span class="se">\</span>
+ <span class="nv">discovery</span><span class="o">=</span>http://localhost:8080/
<span class="se">\</span>
+ <span class="nv">identification</span><span class="o">=</span>MyTarget
<span class="se">\</span>
+ <span class="nv">auth</span><span class="o">=</span>/path/to/connectionfactory/config/files
+</pre></div>
+
+
+<p>Alternatively, one could adapt the code of the management agent to use the <tt>ConfigAdmin</tt>
service directly for creating the individual configurations using the service factory PID
<tt>org.apache.ace.connectionfactory</tt>. </p>
+<h2 id="extending-the-authentication-mechanism">Extending the authentication mechanism</h2>
+<p>…</p>
+<h3 id="authentication-processors">Authentication processors</h3>
 <p>…</p>
+<h3></h3>
 <div class="footnote">
 <hr />
 <ol>



Mime
View raw message