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: r1330279 -
 /ace/site/trunk/content/dev-doc/design/ace-authentication.mdtext
Date: Wed, 25 Apr 2012 13:31:04 -0000
To: commits@ace.apache.org
From: jawi@apache.org
Message-Id: <20120425133104.F3F0623889E0@eris.apache.org>

Author: jawi
Date: Wed Apr 25 13:31:04 2012
New Revision: 1330279

URL: http://svn.apache.org/viewvc?rev=1330279&view=rev
Log:
Wrote the section on configuring the MA.

Modified:
    ace/site/trunk/content/dev-doc/design/ace-authentication.mdtext

Modified: ace/site/trunk/content/dev-doc/design/ace-authentication.mdtext
URL: http://svn.apache.org/viewvc/ace/site/trunk/content/dev-doc/design/ace-authentication.mdtext?rev=1330279&r1=1330278&r2=1330279&view=diff
==============================================================================
--- ace/site/trunk/content/dev-doc/design/ace-authentication.mdtext (original)
+++ ace/site/trunk/content/dev-doc/design/ace-authentication.mdtext Wed Apr 25 13:31:04 2012
@@ -5,7 +5,7 @@ last updated: April 25th, 2012
 
 ## Introduction
 
-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 *authentication*, which gives you the ability to verify the identity of someone. Once the identity is known, one can apply *authentication* in order to determine what actions are allowed and which are not.
+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 *authentication*, which gives you the ability to verify the identity of someone. Once the identity is known, one can apply *authorization* 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.
 
 
@@ -80,13 +80,13 @@ Name | Description | Endpoint | Configur
 <tt>RESTClientServlet</tt> | provides the RESTful interface to ACE |<tt>/client</tt> | <tt>o.a.a.client.rest</tt>
 <tt>VaadinServlet</tt> | provides the Vaadin web interface | <tt>/ace</tt> | <tt>o.a.a.webui.vaadin</tt>
 
-Table 1: Remote services overview. Common prefix of configuration PIDs are abbreviated: <tt>o.a.a</tt> = <tt>org.apache.ace</tt>.
+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>.
 
 ### Configuring authentication for remote services
 
 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:
 
-1. add a **mandatory** configuration property `authentication.enabled = false|true` to their configuration. Although any kind of name for this configuration property can be used, it is *strongly* advised to stick to the same name for all services;
+1. add a **mandatory** 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 *strongly* advised to stick to the same name for all services;
 2. when the configuration of a remote service is updated, it should add a service dependency to the <tt>AuthenticationService</tt>. By making this service *required* when authentication is enabled, and *optional* when authentication is disabled, we can adhere to the requirement of optionality for authentication;
 3. in case authentication is *enabled*, 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.
 
@@ -186,8 +186,25 @@ When this configuration is supplied to t
 
 ### Configuring the management agent
 
+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:
+
+    :::sh
+    [localhost:~/]$ java -jar org.apache.ace.launcher-0.8.1-SNAPSHOT.jar \
+     discovery=http://localhost:8080/ \
+     identification=MyTarget \
+     auth=/path/to/connectionfactory/config/files
+
+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>. 
+
+## Extending the authentication mechanism
+
+â¦
+
+### Authentication processors
+
 â¦
 
+### 
 
 [^1]: Other communication protocols could be used as well. However, currently, only HTTP is natively supported by ACE. For the remainder of this article, we'll assume HTTP as protocol.