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.
