Mailing-List: contact commits-help@ace.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ace.apache.org
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: svn commit: r814365 - in /websites/staging/ace/trunk/content: ./
 dev-doc/design/ace-authentication.html
Date: Wed, 25 Apr 2012 09:58:50 -0000
To: commits@ace.apache.org
From: buildbot@apache.org
Message-Id: <20120425095850.3A4182388A29@eris.apache.org>

Author: buildbot
Date: Wed Apr 25 09:58:49 2012
New Revision: 814365

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 09:58:49 2012
@@ -1 +1 @@
-1330176
+1330179

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 09:58:49 2012
@@ -155,7 +155,7 @@
       <div id="content"><p><em>Enabling authentication in ACE</em></p>
 <p>last updated: April 24th, 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>