ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject svn commit: r1330279 - /ace/site/trunk/content/dev-doc/design/ace-authentication.mdtext
Date Wed, 25 Apr 2012 13:31:04 GMT
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.
 



Mime
View raw message