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>
