ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r930432 - in /websites/staging/ace/trunk/content: ./ docs/ docs/analysis/ docs/design/ docs/design/src/
Date Tue, 25 Nov 2014 11:48:22 GMT
Author: buildbot
Date: Tue Nov 25 11:48:22 2014
New Revision: 930432

Log:
Staging update by buildbot for ace

Added:
    websites/staging/ace/trunk/content/docs/design/auditlog-analysis.html
    websites/staging/ace/trunk/content/docs/design/bundlerepository-analysis.html
    websites/staging/ace/trunk/content/docs/design/security-analysis-flow.svg   (with props)
    websites/staging/ace/trunk/content/docs/design/security-analysis.html
    websites/staging/ace/trunk/content/docs/design/src/security-analysis-flow.graffle   (with props)
    websites/staging/ace/trunk/content/docs/design/template-mechanism.html
Removed:
    websites/staging/ace/trunk/content/docs/analysis/
Modified:
    websites/staging/ace/trunk/content/   (props changed)
    websites/staging/ace/trunk/content/docs/design/index.html
    websites/staging/ace/trunk/content/docs/index.html

Propchange: websites/staging/ace/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue Nov 25 11:48:22 2014
@@ -1 +1 @@
-1641583
+1641589

Added: websites/staging/ace/trunk/content/docs/design/auditlog-analysis.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/design/auditlog-analysis.html (added)
+++ websites/staging/ace/trunk/content/docs/design/auditlog-analysis.html Tue Nov 25 11:48:22 2014
@@ -0,0 +1,201 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+  <head>
+    <title>Audit Log Analysis</title>
+    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+    <meta property="og:image" content="//www.apache.org/images/asf_logo.gif" />
+    <link href="/css/bootstrap.min.css" rel="stylesheet" media="screen">
+    <link href="/css/prettify.css" rel="stylesheet" media="screen">
+    <link href="/css/code.css" rel="stylesheet" media="screen">
+    <script src="//code.jquery.com/jquery.js"></script>
+    <script src="/js/bootstrap.min.js"></script>
+    <script src="/js/prettify.js"></script>
+    
+    
+    
+    <script>
+    $(function () { prettyPrint() })
+    $().dropdown()
+    </script>
+  </head>
+  <body style="padding-top: 50px;">
+    <div class="navbar navbar-fixed-top navbar-inverse">
+      <div class="navbar-inner">
+        <div class="container">
+          <a class="brand" href="/index.html">Apache ACE&trade;</a>
+          <ul class="nav">
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/news.html">News</a>
+      </li>
+      <li>
+        <a href="/on-the-web.html">On the web</a>
+      </li>
+    </ul>
+  </li>
+  <li>
+    <a href="/downloads.html">Downloads</a>
+  </li>
+  <li>
+    <a href="/docs/index.html">Documentation</a>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+      </li>
+      <li>
+        <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+      </li>
+      <li>
+        <a href="/get-involved/continuous-integration.html">Continuous Integration</a>
+      </li>
+      <li>
+        <a href="/get-involved/source-code.html">Source Code</a>
+      </li>
+      <li>
+        <a href="/get-involved/project-team.html">Project Team</a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="https://cwiki.apache.org/confluence/display/ACE/Board+Reports">Board Reports <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="https://cwiki.apache.org/confluence/display/ACE/Index">Homepage <i class="icon-share-alt"></i></a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="http://www.apache.org/">Apache Homepage <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/licenses/">Licenses <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/security/">Security <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/foundation/thanks.html">Thanks <i class="icon-share-alt"></i></a>
+      </li>
+    </ul>
+  </li>
+</ul>
+
+        </div>
+      </div>
+    </div>
+    <div class="container">
+      <p><a href="/"><i class='icon-home'></i> Home</a>&nbsp;&raquo&nbsp;<a href="/docs/">Docs</a>&nbsp;&raquo&nbsp;<a href="/docs/design/">Design</a></p>
+      <h1>Audit Log Analysis</h1>
+      <div class="clear"></div>
+      <div id="content"><p>An audit log is a full historic account of all events that are relevant for a certain object. In this case, we keep audit logs of each target that is managed by the provisioning server.</p>
+<h1 id="problem">Problem</h1>
+<p>The first issue is where to maintain the audit log. On the one hand, one can maintain it on the target, but since the management agent talks to the server, it could keep the log too.</p>
+<p>Then there is the question of how to maintain the log. What events should be in it, and what is an event?</p>
+<p>Finally, the audit log should be readable and query-able, so people can review it.</p>
+<p>The following use cases can be defined:</p>
+<ul>
+<li>Store event. Stores a new event to the audit log.</li>
+<li>Get events. Queries (a subset of) events.</li>
+<li>Merge events. Merges a set of (new) events with the existing events.</li>
+</ul>
+<h1 id="context">Context</h1>
+<p>We basically have two contexts:</p>
+<ul>
+<li>Target, limited resources, so we should use something really "lean and mean".</li>
+<li>Server, scalable solution, expect people to query for (large numbers of) events.</li>
+</ul>
+<h1 id="possible-solutions">Possible solutions</h1>
+<p>As with all repositories, there should be one location where it is edited. In this case, the logical place to do that is on the target itself, since that is where the changes actually occur. In theory, the server also knows, but that theory breaks down if things fail on the target or other parties start manipulating the life cycle of bundles. The target itself can detect such activities.</p>
+<p>The next question is what needs to be logged. And how do we get access to these events?</p>
+<p>When storing events, each event can get a unique sequence number. Sequence numbers start with 1 and can be used to determine if you have the complete log.</p>
+<p>Assuming the target has limited storage, it might not be possible to keep the full log available locally. There are a couple of reasons to replicate this log to a central server:</p>
+<ul>
+<li>space, as said the full log might not fit;</li>
+<li>safety, when the target is somehow (partly) erased or compromised, we don't want to loose the log;</li>
+<li>remote diagnostics, we want to get an overview of the audit log without actually connecting to the target directly.</li>
+</ul>
+<p>When replicating, the following scenarios can occur:</p>
+<ol>
+<li>The target has lost its whole log and really wants to (re)start from sequence number 1.</li>
+<li>The server has lost its whole log and receives a partial log.</li>
+</ol>
+<p>Starting with the second scenario, the server always simply collects incoming audit logs, so its memory can be restored from any number of targets or relay servers that report everything they know (again). Hopefully that will lead to a complete log again. If not, there's not much we can do.</p>
+<p>The first scenario is potentially more problematic, since the target has no way of knowing (for sure) at which sequence number it had arrived when everything was lost. In theory it might ask (relay) servers, but even those might not have been up to date, so that does not work. The only thing it can do here is: Start a new log at sequence number 1. That means we can have more than one log in these cases, and that again means we need to be able to identify which log (of each target) we're talking about. Therefore, when a new log is created, it should contain some unique identifier for that log (an identifier that should not depend on stored information, so for example we could use the current time in milliseconds, that should be fairly unique, or just some random number).</p>
+<p>How to find the central server? Use the discovery service!? This is not that big of a deal.</p>
+<p>Events should at least contain:</p>
+<ul>
+<li>a datestamp, indicating when the event occurred;</li>
+<li>a checksum and/or signature;</li>
+<li>a short, human readable message explaining the event;</li>
+<li>details:<ul>
+<li>in the form of a (possibly multi-line) document</li>
+<li>in the form of a set of properties</li>
+</ul>
+</li>
+</ul>
+<p>The server will add:</p>
+<ul>
+<li>the target ID of the target that logged the event.</li>
+</ul>
+<p>Storage will be resolve differently on the server and target. On the target, using any kind of database would amount to having to include a considerable library, which makes these solutions impractical there. We might want to consider something like that for the server though. The options we have, are:</p>
+<ul>
+<li>Relational database</li>
+<li>Object database</li>
+<li>XML</li>
+<li>DIY</li>
+</ul>
+<p>How do events get logged?</p>
+<ul>
+<li>explicitly, our management agent calls an AuditLog service method;</li>
+<li>implicitly, by logging (certain) events in the system;</li>
+</ul>
+<p>Implicit algorithms can be build on top of the AuditLog service. What we need to monitor is the life cycle layer, which basically means adding a BundleListener and an FrameworkListener. Those capture all state changes of the framework. Technically we can either directly add those listeners, or use EventAdmin if that is available.</p>
+<p>What would be the best way for the target to send audit log updates to the server? I don't think we want the server to poll here, so the target should send updates (periodically). So how does it know what to send?</p>
+<ul>
+<li>it could keep track of the last event it sent, sending newer ones after that;</li>
+<li>it could ask for the list of events the server has;</li>
+<li>it could send its highest log event number, and get back a list of missing events on the server, and then respond with the missing events.</li>
+<li>it could just send everything.</li>
+</ul>
+<h1 id="discussion">Discussion</h1>
+<p>Having two layers for the audit log makes sense:</p>
+<ul>
+<li>The first, lowest, layer is the AuditLog service that gives access to the log. On the one hand it allows people to log messages, on the other it should provide query access. Those should be split into two different interfaces.</li>
+<li>The second layer can build on top of that. It can either be removed completely, which means the responsibility for logging becomes that of the application (probably the management agent). It can be implemented using listeners. Finally, it can be implemented using events.</li>
+</ul>
+<p>On the target we should implement a storage solution ourselves, to keep the actual code small. The code should be able to log events quickly (as that will happen far more often than retrieving them).</p>
+<p>Communication between the target and server should be initiated by the target. The target can basically send two commands to the server:</p>
+<ol>
+<li>My audit log contains sequence number 4-8, tell me your numbers. The server then responds (for example) with 1-6. This indicates we need to send 7-8.</li>
+<li>Here you have events 7-8, can you send me 1-3? The server stores its missing events, and sends you the events it has (always check if what you get is what you requested).</li>
+</ol>
+<p>This is setup in this way so the same commands can also be used by relay servers to replicate logs between server and target.</p>
+<h1 id="conclusion">Conclusion</h1>
+<ul>
+<li>The audit log is maintained on the target.</li>
+<li>On the target, we implement the storage mechanism ourselves to ensure we have a solution with a very small footprint.</li>
+<li>On the server, we use an XStream based solution to store the logs of all the targets.</li>
+<li>Our communication protocol between target and (relay)server however, should probably not rely on XML.</li>
+<li>Our communication protocol between server and (relay)server might rely on XML (determine at design time what makes most sense).</li>
+</ul></div>
+      <hr>
+      <footer>
+        <p>Copyright &#169; 2012-2014 <a href="http://www.apache.org/">The Apache Software Foundation</a>, Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.</p>
+      </footer>
+    </div>
+  </body>
+</html>

Added: websites/staging/ace/trunk/content/docs/design/bundlerepository-analysis.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/design/bundlerepository-analysis.html (added)
+++ websites/staging/ace/trunk/content/docs/design/bundlerepository-analysis.html Tue Nov 25 11:48:22 2014
@@ -0,0 +1,136 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+  <head>
+    <title>Bundle Repository Analysis</title>
+    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+    <meta property="og:image" content="//www.apache.org/images/asf_logo.gif" />
+    <link href="/css/bootstrap.min.css" rel="stylesheet" media="screen">
+    <link href="/css/prettify.css" rel="stylesheet" media="screen">
+    <link href="/css/code.css" rel="stylesheet" media="screen">
+    <script src="//code.jquery.com/jquery.js"></script>
+    <script src="/js/bootstrap.min.js"></script>
+    <script src="/js/prettify.js"></script>
+    
+    
+    
+    <script>
+    $(function () { prettyPrint() })
+    $().dropdown()
+    </script>
+  </head>
+  <body style="padding-top: 50px;">
+    <div class="navbar navbar-fixed-top navbar-inverse">
+      <div class="navbar-inner">
+        <div class="container">
+          <a class="brand" href="/index.html">Apache ACE&trade;</a>
+          <ul class="nav">
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/news.html">News</a>
+      </li>
+      <li>
+        <a href="/on-the-web.html">On the web</a>
+      </li>
+    </ul>
+  </li>
+  <li>
+    <a href="/downloads.html">Downloads</a>
+  </li>
+  <li>
+    <a href="/docs/index.html">Documentation</a>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+      </li>
+      <li>
+        <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+      </li>
+      <li>
+        <a href="/get-involved/continuous-integration.html">Continuous Integration</a>
+      </li>
+      <li>
+        <a href="/get-involved/source-code.html">Source Code</a>
+      </li>
+      <li>
+        <a href="/get-involved/project-team.html">Project Team</a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="https://cwiki.apache.org/confluence/display/ACE/Board+Reports">Board Reports <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="https://cwiki.apache.org/confluence/display/ACE/Index">Homepage <i class="icon-share-alt"></i></a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="http://www.apache.org/">Apache Homepage <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/licenses/">Licenses <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/security/">Security <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/foundation/thanks.html">Thanks <i class="icon-share-alt"></i></a>
+      </li>
+    </ul>
+  </li>
+</ul>
+
+        </div>
+      </div>
+    </div>
+    <div class="container">
+      <p><a href="/"><i class='icon-home'></i> Home</a>&nbsp;&raquo&nbsp;<a href="/docs/">Docs</a>&nbsp;&raquo&nbsp;<a href="/docs/design/">Design</a></p>
+      <h1>Bundle Repository Analysis</h1>
+      <div class="clear"></div>
+      <div id="content"><p>The bundle repository stores actual bundles and other artifacts. It is kept external to be able to leverage existing repositories and better protect the intellectual property of our users.</p>
+<h1 id="problem">Problem</h1>
+<p>The bundle repository is an external repository that stores the actual bundle data and other artifacts. We keep this data external to our system to better protect the intellectual property of our users. Having only the meta-data in our system ensures the bundles and artifacts themselves can remain on a separate, protected network, even when the provisioning server itself is used in a hosted or cloud environment.</p>
+<p>Access to the bundle repository is URL based.</p>
+<p>The use cases are:</p>
+<ul>
+<li>Get bundle, which returns the full bundle. This use case is mandatory, as this is the main goal for having a bundle repository.</li>
+<li>Get bundle meta-data, which returns only the meta-data. This one is nice to have, as it would help us on slow connections when we only want metadata.</li>
+<li>Get a list of (a subset of) all bundles in the repository. When provisioning, we already know what we want. When managing the shop we might have use for querying features and we should seriously look at OBR as an implementation. Also, as part of the Equinox provisioning effort, they are defining a similar model.</li>
+<li>Install/update bundle. Makes the repository editable from the outside.</li>
+<li>Delete bundle. Mentioned separately here because of the dangers of deleting bundles that might still be in use (the repository has no way of knowing what's in use).</li>
+</ul>
+<h1 id="context">Context</h1>
+<p>Whilst we will no doubt create our own bundle repository, it would be a big bonus if we could work with other bundle repositories. OBR comes to mind, but there might be others. Therefore it's important to create an implementation that maps easily onto (for example) an HTTP based repository.</p>
+<p>Our requirement to have URL based access to bundles ensures we can do that.</p>
+<h1 id="possible-solutions">Possible solutions</h1>
+<p>As mentioned before, we basically have two solutions:</p>
+<ol>
+<li>use an existing solution;</li>
+<li>creating our own.</li>
+</ol>
+<h1 id="discussion">Discussion</h1>
+<p>Most use cases can be done either way. If you look at the OSGi Alliance's RFC-112 for OBR, the only thing it does not support is manipulating a repository. You could argue that's because it is beyond the scope, and because currently, OBR can be implemented using any webserver (it's basically just a set of bundles and a single XML descriptor).</p>
+<h1 id="conclusion">Conclusion</h1>
+<p>I think we should create our own implementation of OBR, extending it with editing capabilities, and perhaps subsetting it (at least initially, we might not want a whole requirements, capability and dependency mechanism in there right now, as that's something we deal with inside our provisioning system).</p>
+<p>At the same time, adding these editing capabilities should not mean we cannot still generate static files that can be deployed on an external HTTP server. We do want to add an API for editing, but we don't want to make the whole repository depend on the capability to run code on that server, since we might want to do all maintenance on some client that simply uploads files to a server.</p></div>
+      <hr>
+      <footer>
+        <p>Copyright &#169; 2012-2014 <a href="http://www.apache.org/">The Apache Software Foundation</a>, Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.</p>
+      </footer>
+    </div>
+  </body>
+</html>

Modified: websites/staging/ace/trunk/content/docs/design/index.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/design/index.html (original)
+++ websites/staging/ace/trunk/content/docs/design/index.html Tue Nov 25 11:48:22 2014
@@ -101,14 +101,18 @@
       <p><a href="/"><i class='icon-home'></i> Home</a>&nbsp;&raquo&nbsp;<a href="/docs/">Docs</a>&nbsp;&raquo&nbsp;<a href="/docs/design/">Design</a></p>
       <h1>Design</h1>
       <div class="clear"></div>
-      <div id="content"><h2 id="design-documentation">Design documentation</h2>
-<p>The following documents explain some more details on the design of various aspects in
-Apache ACE. Read them if you want to know more about why certain functionality exists and
-why it is implemented in this way.</p>
+      <div id="content"><h2 id="design-and-analysis-documentation">Design and analysis documentation</h2>
+<p>The following documents explain some more details on the analysis and design of various
+aspects in Apache ACE. Read them if you want to know more about why certain functionality
+exists and why it is implemented in this way.</p>
 <ul>
-<li><a href="auditlog-protocol.html">Audit Log Protocol</a>;</li>
-<li><a href="authentication-design.html">Authentication design</a>;</li>
-<li><a href="remote-interfaces.html">Remote Interfaces</a>.</li>
+<li>The <a href="auditlog-analysis.html">analysis</a> and <a href="auditlog-protocol.html">design</a> of the audit
+  log protocol;</li>
+<li>The <a href="bundlerepository-analysis.html">bundle repository analysis</a>;</li>
+<li>The <a href="security-analysis.html">security analysis</a> and <a href="authentication-design.html">authentication
+  design</a>;</li>
+<li><a href="remote-interfaces.html">Remote Interfaces</a>;</li>
+<li>The design documentation on the <a href="template-mechanism.html">template mechanism</a>.</li>
 </ul></div>
       <hr>
       <footer>

Added: websites/staging/ace/trunk/content/docs/design/security-analysis-flow.svg
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/ace/trunk/content/docs/design/security-analysis-flow.svg
------------------------------------------------------------------------------
    svn:mime-type = image/svg+xml

Added: websites/staging/ace/trunk/content/docs/design/security-analysis.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/design/security-analysis.html (added)
+++ websites/staging/ace/trunk/content/docs/design/security-analysis.html Tue Nov 25 11:48:22 2014
@@ -0,0 +1,155 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+  <head>
+    <title>Security Analysis</title>
+    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+    <meta property="og:image" content="//www.apache.org/images/asf_logo.gif" />
+    <link href="/css/bootstrap.min.css" rel="stylesheet" media="screen">
+    <link href="/css/prettify.css" rel="stylesheet" media="screen">
+    <link href="/css/code.css" rel="stylesheet" media="screen">
+    <script src="//code.jquery.com/jquery.js"></script>
+    <script src="/js/bootstrap.min.js"></script>
+    <script src="/js/prettify.js"></script>
+    
+    
+    
+    <script>
+    $(function () { prettyPrint() })
+    $().dropdown()
+    </script>
+  </head>
+  <body style="padding-top: 50px;">
+    <div class="navbar navbar-fixed-top navbar-inverse">
+      <div class="navbar-inner">
+        <div class="container">
+          <a class="brand" href="/index.html">Apache ACE&trade;</a>
+          <ul class="nav">
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/news.html">News</a>
+      </li>
+      <li>
+        <a href="/on-the-web.html">On the web</a>
+      </li>
+    </ul>
+  </li>
+  <li>
+    <a href="/downloads.html">Downloads</a>
+  </li>
+  <li>
+    <a href="/docs/index.html">Documentation</a>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+      </li>
+      <li>
+        <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+      </li>
+      <li>
+        <a href="/get-involved/continuous-integration.html">Continuous Integration</a>
+      </li>
+      <li>
+        <a href="/get-involved/source-code.html">Source Code</a>
+      </li>
+      <li>
+        <a href="/get-involved/project-team.html">Project Team</a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="https://cwiki.apache.org/confluence/display/ACE/Board+Reports">Board Reports <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="https://cwiki.apache.org/confluence/display/ACE/Index">Homepage <i class="icon-share-alt"></i></a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="http://www.apache.org/">Apache Homepage <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/licenses/">Licenses <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/security/">Security <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/foundation/thanks.html">Thanks <i class="icon-share-alt"></i></a>
+      </li>
+    </ul>
+  </li>
+</ul>
+
+        </div>
+      </div>
+    </div>
+    <div class="container">
+      <p><a href="/"><i class='icon-home'></i> Home</a>&nbsp;&raquo&nbsp;<a href="/docs/">Docs</a>&nbsp;&raquo&nbsp;<a href="/docs/design/">Design</a></p>
+      <h1>Security Analysis</h1>
+      <div class="clear"></div>
+      <div id="content"><p>Security is an important concern for ACE. The analysis needs to differentiate between the individual needs of each sub-system and the overall flow inside the system. Furthermore, several scenarios need to be taken into account and addressed. In general, safety issues are not part of this analysis but will be addressed separately.</p>
+<p>Threat scenarios and possible countermeasures are given subdivided by and investigated in regard to authentication, authorization, integrity, non repudiation, and confidentiality. We need answers to the following questions, what kind of different "attacks" from both external and internal interfaces can we identify (threats); how can we authenticate the different actors (human and machine) so we really know who we're talking to (authentication); who is allowed to do what in the system (authorization); who did what at which point of time (non repudiation); and how do we encrypt and ensure the integrity of the communication/software/configuration data (confidentiality).</p>
+<p>Security on the target and relay server needs special attention because they are most likely provided by a third party, might be accessible from the outside, and not easily reachable for maintenance. It is for example possible that a target is at a remote location, accessible via the internet, and requires days to be accessed physically.</p>
+<h1 id="threat-scenarios">Threat Scenarios</h1>
+<p>This analysis focuses on the OSGi framework and management agent part of the system and its interaction with a (relay) server as well as between the client (for this analysis we assume the client is a separate node, for our web based UI it just happens to be part of the server) and a server. The most likely scenarios are forced breakdown of the system (denial of service attack), malicious data that might change system behavior, attempts to take over control, and espionage.</p>
+<ol>
+<li>(D)DOS - In general, it is not possible to prevent denial of service attacks. Attackers normally can find a way to overload the system. Regarding the management agent it would be for example possible to provide the agent with a huge amount of data to install so that the target either is running out of disk space or out of other processing resources. The same is possible for any other entity in the system if an attacker finds a way to make it accept data.</li>
+<li>Malicious Data - An attacker might use malicious data as part of a DOS attack but it could be also used to gain control over the system or change some aspects of its behavior to make it easier to take over control or cause other harm.</li>
+<li>Hostile Takeover - Attackers might be interested in taking control over (parts of) the system in order to either do espionage, change the behavior of the system to do work for them, or plainly destroy/disable entities (e.g., to harm competitors).</li>
+<li>Eavesdropping - An attacker might be able to listen in on the communication between a target and its (relay-) server or the client and the server. This might allow to learn about the configuration of a target and getting hold of the installed software.</li>
+<li>Physical Access - Another type of attack would be to gain physical access e.g., disassemble a target or a relay server in an attempt to steal its data and/or impersonate it. Probably the only way to avoid that is hardware encryption, which for ACE is out of scope (but can be used to further harden the system).</li>
+</ol>
+<h1 id="countermeasures">Countermeasures</h1>
+<p>On the target there are two entities that are important namely, the (relay) server which is providing the target with instructions and data/code, and the management agent (i.e., the target itself). Regarding the communication between a client and the server the secure checkout and commit of object repository versions are important as well as the auditlog. The interaction between the server and a relay server is a two way data exchange where the relay server is comparable to a target in regard to the instructions and data/code it needs to get from the server and to a server that sends the auditlog to a client. One plus point from the security side is that the target is only polling the server – hence, it is not accepting any connection requests from the outside. This reduces the risk of a DOS attack but by no means makes it invulnerable against it (especially since there is a high likelihood that the underlying platform is vulnerable to DOS attacks as well). One way of workin
 g around the polling restrictions are ARP and DNS injection attacks that might make the target contact the wrong server. This allows for malicious data, DOS attacks, and hostile takeovers.</p>
+<p>A good start to limit attack possibilities is to decouple the sub-net of the target from the internet / external world by using relay servers but this doesn't prevent the mentioned attacks and threats in all cases. Furthermore, relay servers need to support both polling and being polled due to their different roles (they are polled by the targets, need to poll deployment packages or object repositories from the server, and push the auditlogs of targets to the server). Finally, the server is only polled.</p>
+<h3 id="authentication">Authentication</h3>
+<p>As mentioned above, the most likely way of attacking a target or relay server is to spoof its connection to the server (whether it is a relay server or the real one). It is dangerous to rely on DNS and/or IP addresses because both might be wrong. Given the issues at stake, authentication will need to be based on certificates. An entity of the system should have a certificate (that has the id as part of it's common name) as its identity.</p>
+<p>Furthermore, it needs to have a keystore of trusted root certificates (CA) and a certificate revocation list (CRL). The (relay) server needs to have a certificate as its identity that is part of a chain of trust to one of the trusted root certificates of the target or client and vice versa. Basically, this can be achieved via two ways, one is to use https with server and client certificates; the other to use certificates to sign all messages/data using our own protocol.</p>
+<h3 id="authorization">Authorization</h3>
+<p>We have to differentiate between several areas where authorization is needed. The provisioning part needs to make sure it is installing deployment packages from an authorized server.</p>
+<p>The target itself is running an OSGi framework and can subsequently, make use of the built-in security. This is needed if deployed software components can not be trusted and would be advisable to foster "least privilege" security in general. However, the management agent will need to be able to cooperate with the framework infrastructure to set-up needed rights. Special care needs to be taken to avoid installing malicious software in a framework with security disabled or with too powerful a set of rights. Due to the life-cycle capabilities of OSGi, a malicious or faulty bundle could for example uninstall the management agent itself if the bundle is started in the absence of security or with admin permission (This aspect is not part of this analysis and will be discussed as a separate user story).</p>
+<p>Assuming the additional requirements in regard to integrity and authentication are satisfied it should be sufficient to ensure the server is authorized to make changes to the target – hence, in a certificate based approach separate chains of trust can be used to determine whether a server is trusted and is authoritative for a given target. In other words, the certificate of the server can be treated as a capability (revocation is then possible via a certificate revocation list). The same applies for clients and relay servers, respectively.</p>
+<h3 id="integrity">Integrity</h3>
+<p>Due to the fact that authorization to provision a given version (i.e., a set of bundles) is mainly based on whether or not the current authenticated server is authoritative for a target it is of great importance that the actual deployment package has not been tampered with.</p>
+<p>The deployment admin specification already defines a way to ensure integrity building upon the fact that deployment packages are Java JAR files (which can be signed). Therefore, it makes sense to only allow deployment packages that are signed by a certificate that the target has in a chain of trust.</p>
+<p>Furthermore, taking into account relay servers the trusted certificates can be limited further to for example only allow the actual server certificate.</p>
+<p>Deployment packages can be signed by any number of certificates so it is possible to sign a deployment package multiple times in order to make it available to different targets that follow non uniform certificate trust strategies. The same is possible for the object repositories and the auditlog.</p>
+<h3 id="non-repudiation">Non Repudiation</h3>
+<p>Several entities can be responsible for changes in the system. The individual entities need to make sure they record in a non repudiation fashion who was doing what for any action taken. Conversely, the server and possibly the relay servers need a way to ensure that for example auditlog entries are really from the target they are claimed to be.</p>
+<p>One way to tackle this is to use certificates to sign all data and to make sure that for all data accepted from a different entity, the signature (including the fingerprint of the signing certificate) is recorded. Taking the auditlog as an example, a target would use its certificate to sign all entries in the auditlog. Subsequently, a server or a client can be certain that a given auditlog is originating from the target it is claimed to come from (assuming the private key of the target certificate has not been exploited).</p>
+<p>Furthermore, it will be easy to invalidate data from compromised entities by adding their certificates to the certificate revocation list.</p>
+<p>Another, more involved example, can be a target that receives a deployment package and installs it. In this case, the manifest containing all the signatures of the content of the signed deployment package as well as all the fingerprints of the certificates that signed it need to be added to the targets auditlog and this entry would be signed by the target certificate. After the log is synchronized back to the server (possibly via several relay servers or even manually) the server can determine who signed the deployment package and where it has been installed. The same applies for clients.</p>
+<h3 id="confidentiality">Confidentiality</h3>
+<p>In most cases the software that needs to be provisioned as well as the configuration of the targets needs to be kept confidential since it may contain business secrets. This can only be ensured by means of encryption because we have to take scenarios into account where communication happens via a none secure channel like the internet.</p>
+<p>One secure set-up would be to use asynchronous encryption which would furthermore not rely on a point-to-point protocol but rather enable all the way confidentiality. Alas, the deployment packages might be big and asynchronous encryption would be to slow in this case.</p>
+<p>The alternative is to use SSL (most likely by means of HTTPS). The downside of SSL as for example in HTTPS is that it is often hard to set-up and relatively inconvenient and static to use if the possibility of a man in the middle attack needs to be ruled out.</p>
+<p>Possibly the biggest problem, in our scenario, is that we can not assume that the common name of an entity reflects its IP/DNS name. Relay servers might be operating in networks not under the customers or our control and the same applies to targets and clients (which could have dynamic IP's and hostnames for example). This problem can be overcome by ignoring the common name in regard to authentication which might make it necessary to create some integration code for certain platforms and containers (e.g., the JVM, by default, assumes that it can resolve the common name as a host name). The downside is that such an approach would open the possibility for man in the middle attacks. Only in combination with client certificates this can be prevented (alas, this might need some more adaption on the server side).</p>
+<p>Finally, the certificates on both, the server and the target side, respectively, would need to be in a chain of trust. Assuming this precondition holds, the only way to eavesdrop would then be to exploit one of the certificate's private key (e.g., via disassembling the target by an attacker that has physical access or by means of gaining access to the target via a different vulnerability). Such a key could be blacklisted by adding it to the certificate revocation list upon discovery of its exploitation.</p>
+<h3 id="encryption">Encryption</h3>
+<p>The physical access threat makes it possible that attackers might get hold of data (like installed bundles). Https and certificates can prevent eavesdropping while data is distributed but if an attacker can get hold of the target or a relay server it is still possible to access the data. As mentioned above, for the target the only way to prevent this would be hardware supported encryption but for relay servers it is sufficient to encrypt the data itself. We might need to support this eventually but it is not looked into further in this analysis.</p>
+<h1 id="certificate-based-flow-analysis">Certificate based Flow Analysis</h1>
+<p>All entities (the server, the client, the relay server, and the target), have a CRL and a keystore; the former contains revoked certificates and the later the known and trusted certificate authorities. In general, for all involved certificates, for a certificate to be valid it has to be the case that it is in a chain-of-trust relation to at least one of the trusted certificate authorities and is not revoked. Furthermore, there exists a special trusted certificate known as the server authority and vice versa for the target and client. The interaction between the entities is via HTTPS and needs a valid server and client certificate. The common name of the certificate represents the target, client, or server id, respectively. As a further restriction the server certificate has to be in a chain of trust to the server certificate authority, the client certificate has to be in a chain of trust to the client certificate authority, and the target certificate has to be in a chain of trust
  to the target certificate authority. The data exchanged between the entities needs to be signed by the respective counterpart certificate authority. For example, a deployment package send from the server to the target needs to be signed by a valid certificate that is in a chain of trust to the server certificate authority and auditlog entries send from the target to the server must be signed by its target certificate. In other words, the signer needs to be the one that created the specific data. CLR and keystore can be treated as yet another object repository (because they need to be signed) – hence, they can be synced from a server to clients, relay servers, and subsequently, targets.</p>
+<p><object data="security-analysis-flow.svg" type="image/svg+xml" class="span12" height="868"></object></p>
+<h1 id="conclusion">Conclusion</h1>
+<p>The set-up takes aforementioned countermeasure to the identified threat into account. The https connection ensures the confidentiality via encryption. Due to the server and client certificate connection authentication and authorization are addressed. The requirement of separately signed content provides integrity and non repudiation in the absence of compromised certificate private keys. Certificates with known exploited keys can be revoked by adding them to the CRLs. Authority derives from the chain of trust relation to the server and target certificate authority.</p></div>
+      <hr>
+      <footer>
+        <p>Copyright &#169; 2012-2014 <a href="http://www.apache.org/">The Apache Software Foundation</a>, Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.</p>
+      </footer>
+    </div>
+  </body>
+</html>

Added: websites/staging/ace/trunk/content/docs/design/src/security-analysis-flow.graffle
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/ace/trunk/content/docs/design/src/security-analysis-flow.graffle
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/ace/trunk/content/docs/design/template-mechanism.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/design/template-mechanism.html (added)
+++ websites/staging/ace/trunk/content/docs/design/template-mechanism.html Tue Nov 25 11:48:22 2014
@@ -0,0 +1,133 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+  <head>
+    <title>Template Mechanism</title>
+    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+    <meta property="og:image" content="//www.apache.org/images/asf_logo.gif" />
+    <link href="/css/bootstrap.min.css" rel="stylesheet" media="screen">
+    <link href="/css/prettify.css" rel="stylesheet" media="screen">
+    <link href="/css/code.css" rel="stylesheet" media="screen">
+    <script src="//code.jquery.com/jquery.js"></script>
+    <script src="/js/bootstrap.min.js"></script>
+    <script src="/js/prettify.js"></script>
+    
+    
+    
+    <script>
+    $(function () { prettyPrint() })
+    $().dropdown()
+    </script>
+  </head>
+  <body style="padding-top: 50px;">
+    <div class="navbar navbar-fixed-top navbar-inverse">
+      <div class="navbar-inner">
+        <div class="container">
+          <a class="brand" href="/index.html">Apache ACE&trade;</a>
+          <ul class="nav">
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/news.html">News</a>
+      </li>
+      <li>
+        <a href="/on-the-web.html">On the web</a>
+      </li>
+    </ul>
+  </li>
+  <li>
+    <a href="/downloads.html">Downloads</a>
+  </li>
+  <li>
+    <a href="/docs/index.html">Documentation</a>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+      </li>
+      <li>
+        <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+      </li>
+      <li>
+        <a href="/get-involved/continuous-integration.html">Continuous Integration</a>
+      </li>
+      <li>
+        <a href="/get-involved/source-code.html">Source Code</a>
+      </li>
+      <li>
+        <a href="/get-involved/project-team.html">Project Team</a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="https://cwiki.apache.org/confluence/display/ACE/Board+Reports">Board Reports <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="https://cwiki.apache.org/confluence/display/ACE/Index">Homepage <i class="icon-share-alt"></i></a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="http://www.apache.org/">Apache Homepage <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/licenses/">Licenses <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/security/">Security <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="http://www.apache.org/foundation/thanks.html">Thanks <i class="icon-share-alt"></i></a>
+      </li>
+    </ul>
+  </li>
+</ul>
+
+        </div>
+      </div>
+    </div>
+    <div class="container">
+      <p><a href="/"><i class='icon-home'></i> Home</a>&nbsp;&raquo&nbsp;<a href="/docs/">Docs</a>&nbsp;&raquo&nbsp;<a href="/docs/design/">Design</a></p>
+      <h1>Template Mechanism</h1>
+      <div class="clear"></div>
+      <div id="content"><p>Some artifacts (see Object Graph in Client) can need some customization before being provisioned, e.g. configuration files might need some information that is managed by one of the distributions.</p>
+<p>The customization will be done when a new version is created, i.e., on call of <code>approve()</code> on a StatefulTargetObject. A customized version of the artifact (which is located somewhere in an OBR, reachable using a URL) is uploaded to the same OBR, and the URL to the customized one is stored in the DeploymentVersionObject.</p>
+<h1 id="proposed-design">Proposed design</h1>
+<p>In addition to the interfaces ArtifactHelper and ArtifactRecognizer, we introduce a ArtifactPreprocessor, which has a single method <code>preprocess(ArtifactObject object, Properties props)</code>, in which Properties contains customization information (see below), and the method returns the URL of the altered artifact (or, if nothing has changed, the original artifact, or, if this changed artifact is identical to one that has already been created before, that old URL). This ArtifactPreprocessor can be published as a service (see the section on remoting below), but for local purposes, the ArtifactHelper interface gets an extra method <code>getPreprocessor()</code>, which returns an instance of the preprocessor to be used for the type of artifact this helper helps.</p>
+<p>As an added service, we could create a basic preprocessor, VelocityBasedPreprocessor which uses the Velocity template engine to process an artifact and store it in a configured OBR; this preprocessor can be instantiated and returned by each ArtifactHelper that needs a basic processor (if no processing can be done for some type of artifact, <code>getPreprocessor</code> should return null).</p>
+<h3 id="customization-information">Customization information</h3>
+<p>For each template that has 'holes' to fill in, it can 'reach' all RepositoryObjects that are reachable from the TargetObject this template will be provisioned to, leading to a tree of data. Inspired by Velocity's way of finding contextual data, we propose to store the for each RepositoryObject in its own Properties object, adding its attributes and tags to it as two Properties objects using the keys "attributes" and "tags", and a List<Properties> summing up all children (so, for a target, all its distributions) using the key "children"; in the end, this becomes a tree of Properties objects.</p>
+<p>This way, the Velocity template can use syntax like</p>
+<div class="codehilite"><pre><span class="c">#foreach( $license in $gateway.children)</span>
+    <span class="c">#if ($license.attributes.vendor==&quot;luminis&quot;)</span>
+        <span class="n">Default</span> <span class="nb">license</span> <span class="n">by</span> <span class="n">luminis</span>
+    <span class="c">#else</span>
+        <span class="n">Custom</span> <span class="nb">license</span> <span class="n">by</span> $<span class="nb">license</span><span class="p">.</span><span class="n">attributes</span><span class="p">.</span><span class="n">vendor</span>
+    <span class="c">#end</span>
+<span class="c">#end</span>
+</pre></div>
+
+
+<h3 id="support-for-remoting">Support for remoting</h3>
+<p>Some customers might want to keep all information hidden from us, only allowing us the metadata on the server. In this case, we can deploy a ArtifactPreprocessor on the customer's site, which is then responsible for doing everything a local ArtifactPreprocessor can do, and returning a URL to the altered artifact. Then, in stead of returning an instance of the ArtifactPreprocessor, the ArtifactHelper will return some RemoteArtifactPreprocessor which implements the ArtifactPreprocessor interface, but talks to a servlet on the customer's server.</p>
+<h3 id="on-the-needsapprove-state-in-the-statefultargetobject">On the 'needsApprove' state in the StatefulTargetObject</h3>
+<p>With the mechanism above, <code>determineStoreState</code> in StatefulTargetObject would need to create a full deployment version every time we need to know whether approval is necessary. This is undesirable, because, in a remoting scenario, it means we have to pass lots of data to a servlet, oftentimes only to find out that we created a version identical to the one we already had.
+So, in stead of this rigid semantics, the 'needsApprove' state will become more of a 'tainted' state, which becomes true when something happens that could have an impact on this StatefulTargetObject. We can quite easily determine what targets are affected by a given change in the model by following the associations from that object to the targets.</p></div>
+      <hr>
+      <footer>
+        <p>Copyright &#169; 2012-2014 <a href="http://www.apache.org/">The Apache Software Foundation</a>, Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.</p>
+      </footer>
+    </div>
+  </body>
+</html>

Modified: websites/staging/ace/trunk/content/docs/index.html
==============================================================================
--- websites/staging/ace/trunk/content/docs/index.html (original)
+++ websites/staging/ace/trunk/content/docs/index.html Tue Nov 25 11:48:22 2014
@@ -130,8 +130,6 @@ background</a>.</p>
   guide</a>;</li>
 <li>adding support for new types of artifacts is described in <a href="adding-custom-artifact-types.html">custom artifact type
   documentation</a>;</li>
-<li>if you are interested about the various roles and terminology used in Apache ACE, read
-  <a href="ace-roles.html">roles and terminology page</a>;</li>
 <li>to handle a large number of targets, you can make use of <a href="configuring-relay-servers.html">intermediate relay
   servers</a>;</li>
 <li>configuring HTTP Basic authentication in ACE is described in the <a href="using-basic-auth.html">authentication
@@ -140,6 +138,8 @@ background</a>.</p>
   certificates</a>;</li>
 <li>various deployment strategies for Apache ACE are described in the <a href="ace-deployment-strategies.html">ACE deployment
   strategies document</a>;</li>
+<li>if you are interested in performing load tests, or want to get started with automating
+  ACE deployments, read all about it in our <a href="test-script.html">test script document</a>;</li>
 </ul>
 <h2 id="developing-for-apache-ace">Developing for Apache ACE</h2>
 <p>There are several resources available on extending and developing for Apache ACE, such as:</p>
@@ -157,20 +157,11 @@ background</a>.</p>
 </ul>
 <h2 id="background-information-designs-and-analysis">Background information, designs and analysis</h2>
 <ul>
-<li>if you are interested in performing load tests, or want to get started with automating
-  ACE deployments, read all about it in our <a href="test-script.html">test script
-  document</a>;</li>
+<li>if you are interested about the various roles and terminology used in Apache ACE, read
+  <a href="ace-roles.html">roles and terminology page</a>;</li>
 <li>various use cases are described on the <a href="use-cases">use cases page</a>;</li>
-<li>detailed analysis documentation giving background information on some development
-  principles currently used:</li>
-<li><a href="analysis/auditlog-analysis.html">audit log analysis</a>;</li>
-<li><a href="analysis/bundlerepository-analysis.html">bundle repository analysis</a>;</li>
-<li><a href="analysis/security-analysis.html">security analysis</a>;</li>
-<li><a href="analysis/template-mechanism.html">template mechanism</a>.</li>
-<li>detailed design documentation:</li>
-<li><a href="design/authentication-design.html">authentication design</a>;</li>
-<li><a href="design/remote-interfaces.html">remote interface design</a>;</li>
-<li><a href="design/auditlog-protocol.html">audit log details</a>;</li>
+<li>to get more details on the why and how of certain parts of ACE can be found in the
+  <a href="design/index.html">design and analysis documentation</a>.</li>
 </ul></div>
       <hr>
       <footer>



Mime
View raw message