Author: jawi
Date: Tue Nov 25 11:48:16 2014
New Revision: 1641589
URL: http://svn.apache.org/r1641589
Log:
Merged the analysis and design to a single source of background information.
Added:
ace/site/trunk/content/docs/design/auditlog-analysis.mdtext (with props)
ace/site/trunk/content/docs/design/bundlerepository-analysis.mdtext (with
props)
ace/site/trunk/content/docs/design/security-analysis-flow.svg (with props)
ace/site/trunk/content/docs/design/security-analysis.mdtext (with props)
ace/site/trunk/content/docs/design/src/security-analysis-flow.graffle
(with props)
ace/site/trunk/content/docs/design/template-mechanism.mdtext (with props)
Removed:
ace/site/trunk/content/docs/analysis/
Modified:
ace/site/trunk/content/docs/design/index.mdtext
ace/site/trunk/content/docs/index.mdtext
Added: ace/site/trunk/content/docs/design/auditlog-analysis.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/design/auditlog-analysis.mdtext?rev=1641589&view=auto
==============================================================================
--- ace/site/trunk/content/docs/design/auditlog-analysis.mdtext (added)
+++ ace/site/trunk/content/docs/design/auditlog-analysis.mdtext Tue Nov 25
11:48:16 2014
@@ -0,0 +1,112 @@
+Title: Audit Log Analysis
+
+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.
+
+Problem
+=======
+
+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.
+
+Then there is the question of how to maintain the log. What events should be
in it, and what is an event?
+
+Finally, the audit log should be readable and query-able, so people can review
it.
+
+The following use cases can be defined:
+
+* Store event. Stores a new event to the audit log.
+* Get events. Queries (a subset of) events.
+* Merge events. Merges a set of (new) events with the existing events.
+
+Context
+=======
+
+We basically have two contexts:
+
+* Target, limited resources, so we should use something really "lean and mean".
+* Server, scalable solution, expect people to query for (large numbers of)
events.
+
+Possible solutions
+==================
+
+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.
+
+The next question is what needs to be logged. And how do we get access to
these events?
+
+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.
+
+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:
+
+* space, as said the full log might not fit;
+* safety, when the target is somehow (partly) erased or compromised, we don't
want to loose the log;
+* remote diagnostics, we want to get an overview of the audit log without
actually connecting to the target directly.
+
+When replicating, the following scenarios can occur:
+
+1. The target has lost its whole log and really wants to (re)start from
sequence number 1.
+2. The server has lost its whole log and receives a partial log.
+
+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.
+
+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).
+
+How to find the central server? Use the discovery service!? This is not that
big of a deal.
+
+Events should at least contain:
+
+* a datestamp, indicating when the event occurred;
+* a checksum and/or signature;
+* a short, human readable message explaining the event;
+* details:
+ * in the form of a (possibly multi-line) document
+ * in the form of a set of properties
+
+The server will add:
+
+* the target ID of the target that logged the event.
+
+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:
+
+* Relational database
+* Object database
+* XML
+* DIY
+
+How do events get logged?
+
+* explicitly, our management agent calls an AuditLog service method;
+* implicitly, by logging (certain) events in the system;
+
+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.
+
+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?
+
+* it could keep track of the last event it sent, sending newer ones after that;
+* it could ask for the list of events the server has;
+* 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.
+* it could just send everything.
+
+Discussion
+==========
+
+Having two layers for the audit log makes sense:
+
+* 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.
+* 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.
+
+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).
+
+Communication between the target and server should be initiated by the target.
The target can basically send two commands to the server:
+
+1. 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.
+2. 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).
+
+This is setup in this way so the same commands can also be used by relay
servers to replicate logs between server and target.
+
+Conclusion
+==========
+
+* The audit log is maintained on the target.
+* On the target, we implement the storage mechanism ourselves to ensure we
have a solution with a very small footprint.
+* On the server, we use an XStream based solution to store the logs of all the
targets.
+* Our communication protocol between target and (relay)server however, should
probably not rely on XML.
+* Our communication protocol between server and (relay)server might rely on
XML (determine at design time what makes most sense).
Propchange: ace/site/trunk/content/docs/design/auditlog-analysis.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Added: ace/site/trunk/content/docs/design/bundlerepository-analysis.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/design/bundlerepository-analysis.mdtext?rev=1641589&view=auto
==============================================================================
--- ace/site/trunk/content/docs/design/bundlerepository-analysis.mdtext (added)
+++ ace/site/trunk/content/docs/design/bundlerepository-analysis.mdtext Tue Nov
25 11:48:16 2014
@@ -0,0 +1,45 @@
+Title: Bundle Repository Analysis
+
+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.
+
+Problem
+=======
+
+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.
+
+Access to the bundle repository is URL based.
+
+The use cases are:
+
+* Get bundle, which returns the full bundle. This use case is mandatory, as
this is the main goal for having a bundle repository.
+* 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.
+* 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.
+* Install/update bundle. Makes the repository editable from the outside.
+* 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).
+
+Context
+=======
+
+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.
+
+Our requirement to have URL based access to bundles ensures we can do that.
+
+Possible solutions
+==================
+
+As mentioned before, we basically have two solutions:
+
+1. use an existing solution;
+2. creating our own.
+
+Discussion
+==========
+
+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).
+
+Conclusion
+==========
+
+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).
+
+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.
\ No newline at end of file
Propchange: ace/site/trunk/content/docs/design/bundlerepository-analysis.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Modified: ace/site/trunk/content/docs/design/index.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/design/index.mdtext?rev=1641589&r1=1641588&r2=1641589&view=diff
==============================================================================
--- ace/site/trunk/content/docs/design/index.mdtext (original)
+++ ace/site/trunk/content/docs/design/index.mdtext Tue Nov 25 11:48:16 2014
@@ -1,12 +1,16 @@
Title: Design
-## Design documentation
+## Design and analysis documentation
-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.
+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.
-* [Audit Log Protocol](auditlog-protocol.html);
-* [Authentication design](authentication-design.html);
-* [Remote Interfaces](remote-interfaces.html).
+* The [analysis](auditlog-analysis.html) and [design](auditlog-protocol.html)
of the audit
+ log protocol;
+* The [bundle repository analysis](bundlerepository-analysis.html);
+* The [security analysis](security-analysis.html) and [authentication
+ design](authentication-design.html);
+* [Remote Interfaces](remote-interfaces.html);
+* The design documentation on the [template
mechanism](template-mechanism.html).
Added: ace/site/trunk/content/docs/design/security-analysis-flow.svg
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/design/security-analysis-flow.svg?rev=1641589&view=auto
==============================================================================
--- ace/site/trunk/content/docs/design/security-analysis-flow.svg (added)
+++ ace/site/trunk/content/docs/design/security-analysis-flow.svg Tue Nov 25
11:48:16 2014
@@ -0,0 +1,3 @@
+<?xml version="1.0"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>
+<svg xmlns="http://www.w3.org/2000/svg";
xmlns:xl="http://www.w3.org/1999/xlink"; version="1.1" viewBox="-3 -3 584 539"
width="584pt" height="539pt"><metadata
xmlns:dc="http://purl.org/dc/elements/1.1/";><dc:date>2012-03-30
07:38Z</dc:date><!-- Produced by OmniGraffle Professional 5.3.6
--></metadata><defs><filter id="Shadow"
filterUnits="userSpaceOnUse"><feGaussianBlur in="SourceAlpha" result="blur"
stdDeviation="3.488"/><feOffset in="blur" result="offset" dx="0"
dy="4"/><feFlood flood-color="black" flood-opacity=".75"
result="flood"/><feComposite in="flood" in2="offset"
operator="in"/></filter><font-face font-family="Arial" font-size="11"
panose-1="2 11 6 4 2 2 2 2 2 4" units-per-em="1000"
underline-position="-105.95703" underline-thickness="73.242188" slope="0"
x-height="518.5547" cap-height="716.3086" ascent="905.27344"
descent="-211.91406" font-weight="500"><font-face-src><font-face-name
name="ArialMT"/></font-face-src></font-face><marker orient="auto"
overflow="visible" markerUni
ts="strokeWidth" id="FilledArrow_Marker" viewBox="-1 -4 10 8" markerWidth="10"
markerHeight="8" color="black"><g><path d="M 8 0 L 0 -3 L 0 3 Z"
fill="currentColor" stroke="currentColor"
stroke-width="1"/></g></marker><marker orient="auto" overflow="visible"
markerUnits="strokeWidth" id="FilledArrow_Marker_2" viewBox="-9 -4 10 8"
markerWidth="10" markerHeight="8" color="black"><g><path d="M -8 0 L 0 3 L 0 -3
Z" fill="currentColor" stroke="currentColor"
stroke-width="1"/></g></marker></defs><g stroke="none" stroke-opacity="1"
stroke-dasharray="none" fill="none" fill-opacity="1"><title>Canvas
1</title><g><title>Layer 1</title><g><use xl:href="#id3_Graphic"
filter="url(#Shadow)"/><use xl:href="#id4_Graphic" filter="url(#Shadow)"/><use
xl:href="#id5_Graphic" filter="url(#Shadow)"/><use xl:href="#id6_Graphic"
filter="url(#Shadow)"/><use xl:href="#id7_Graphic" filter="url(#Shadow)"/><use
xl:href="#id8_Graphic" filter="url(#Shadow)"/><use xl:href="#id14_Graphic"
filter="url(#Shadow)"/><use
xl:href="#id17_Graphic" filter="url(#Shadow)"/><use xl:href="#id19_Graphic"
filter="url(#Shadow)"/><use xl:href="#id20_Graphic" filter="url(#Shadow)"/><use
xl:href="#id21_Graphic" filter="url(#Shadow)"/><use xl:href="#id22_Graphic"
filter="url(#Shadow)"/><use xl:href="#id23_Graphic" filter="url(#Shadow)"/><use
xl:href="#id24_Graphic" filter="url(#Shadow)"/><use xl:href="#id25_Graphic"
filter="url(#Shadow)"/><use xl:href="#id26_Graphic" filter="url(#Shadow)"/><use
xl:href="#id27_Graphic" filter="url(#Shadow)"/><use xl:href="#id28_Graphic"
filter="url(#Shadow)"/><use xl:href="#id29_Graphic" filter="url(#Shadow)"/><use
xl:href="#id16_Graphic" filter="url(#Shadow)"/><use xl:href="#id15_Graphic"
filter="url(#Shadow)"/><use xl:href="#id43_Graphic" filter="url(#Shadow)"/><use
xl:href="#id51_Graphic" filter="url(#Shadow)"/><use xl:href="#id12_Graphic"
filter="url(#Shadow)"/><use xl:href="#id56_Graphic" filter="url(#Shadow)"/><use
xl:href="#id50_Graphic" filter="url(#Shadow)"/><use xl:href="
#id13_Graphic" filter="url(#Shadow)"/><use xl:href="#id61_Graphic"
filter="url(#Shadow)"/><use xl:href="#id62_Graphic" filter="url(#Shadow)"/><use
xl:href="#id63_Graphic" filter="url(#Shadow)"/><use xl:href="#id64_Graphic"
filter="url(#Shadow)"/><use xl:href="#id65_Graphic" filter="url(#Shadow)"/><use
xl:href="#id66_Graphic" filter="url(#Shadow)"/><use xl:href="#id67_Graphic"
filter="url(#Shadow)"/><use xl:href="#id68_Graphic" filter="url(#Shadow)"/><use
xl:href="#id69_Graphic" filter="url(#Shadow)"/><use xl:href="#id70_Graphic"
filter="url(#Shadow)"/><use xl:href="#id71_Graphic"
filter="url(#Shadow)"/></g><g id="id3_Graphic"><path d="M 22 139.00012 L 66
139.00012 C 68.76142 139.00012 71 141.23869 71 144.00012 L 71 240.00012 C 71
242.76155 68.76142 245.00012 66 245.00012 L 22 245.00012 C 19.238577 245.00012
17 242.76155 17 240.00012 C 17 240.00012 17 240.00012 17 240.00012 L 16.999996
144.00012 C 16.999996 141.23869 19.238573 139.00012 21.999996 139.00012 Z"
fill="white"/><path d="M
22 139.00012 L 66 139.00012 C 68.76142 139.00012 71 141.23869 71 144.00012 L
71 240.00012 C 71 242.76155 68.76142 245.00012 66 245.00012 L 22 245.00012 C
19.238577 245.00012 17 242.76155 17 240.00012 C 17 240.00012 17 240.00012 17
240.00012 L 16.999996 144.00012 C 16.999996 141.23869 19.238573 139.00012
21.999996 139.00012 Z" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(22
186.00012)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="9.1604004" y="10"
textLength="25.679199">client</tspan></text></g><g id="id4_Graphic"><path d="M
161 139.00012 L 205 139.00012 C 207.76143 139.00012 210 141.23869 210 144.00012
L 210 240.00012 C 210 242.76155 207.76143 245.00012 205 245.00012 L 161
245.00012 C 158.23857 245.00012 156 242.76155 156 240.00012 C 156 240.00012 156
240.00012 156 240.00012 L 156 144.00012 C 156 141.23869 158.23857 139.00012 161
139.00012 Z" fill="white"/><path d="M 161 139.00012 L 205 139
.00012 C 207.76143 139.00012 210 141.23869 210 144.00012 L 210 240.00012 C 210
242.76155 207.76143 245.00012 205 245.00012 L 161 245.00012 C 158.23857
245.00012 156 242.76155 156 240.00012 C 156 240.00012 156 240.00012 156
240.00012 L 156 144.00012 C 156 141.23869 158.23857 139.00012 161 139.00012 Z"
stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(161 186.00012)"
fill="black"><tspan font-family="Arial" font-size="11" font-weight="500"
x="6.7192383" y="10" textLength="30.561523">server</tspan></text></g><g
id="id5_Graphic"><path d="M 439 139.00012 L 483 139.00012 C 485.7614 139.00012
488 141.23869 488 144.00012 L 488 240.00012 C 488 242.76155 485.7614 245.00012
483 245.00012 L 439 245.00012 C 436.23859 245.00012 434 242.76155 434 240.00012
C 434 240.00012 434 240.00012 434 240.00012 L 434 144.00012 C 434 141.23869
436.23859 139.00012 439 139.00012 Z" fill="white"/><path d="M 439 139.00012 L
483 139.00012 C 485.7614 139.00012
488 141.23869 488 144.00012 L 488 240.00012 C 488 242.76155 485.7614 245.00012
483 245.00012 L 439 245.00012 C 436.23859 245.00012 434 242.76155 434 240.00012
C 434 240.00012 434 240.00012 434 240.00012 L 434 144.00012 C 434 141.23869
436.23859 139.00012 439 139.00012 Z" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(439
186.00012)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="7.935791" y="10"
textLength="28.128418">target</tspan></text></g><g id="id6_Graphic"><path d="M
300 139.00012 L 344 139.00012 C 346.76141 139.00012 349 141.23869 349 144.00012
L 349 240.00012 C 349 242.76155 346.76141 245.00012 344 245.00012 L 300
245.00012 C 297.23859 245.00012 295 242.76155 295 240.00012 C 295 240.00012 295
240.00012 295 240.00012 L 295 144.00012 C 295 141.23869 297.23859 139.00012 300
139.00012 Z" fill="white"/><path d="M 300 139.00012 L 344 139.00012 C 346.76141
139.00012 349 141.23869 349 144.00012
L 349 240.00012 C 349 242.76155 346.76141 245.00012 344 245.00012 L 300
245.00012 C 297.23859 245.00012 295 242.76155 295 240.00012 C 295 240.00012 295
240.00012 295 240.00012 L 295 144.00012 C 295 141.23869 297.23859 139.00012 300
139.00012 Z" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(300 180.00012)"
fill="black"><tspan font-family="Arial" font-size="11" font-weight="500"
x="10.0788574" y="10" textLength="26.898438">relay </tspan><tspan
font-family="Arial" font-size="11" font-weight="500" x="6.7192383" y="22"
textLength="30.561523">server</tspan></text></g><g id="id7_Graphic"><rect
x="17.000002" y="261.00012" width="54" height="31" fill="white"/><rect
x="17.000002" y="261.00012" width="54" height="31" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(22 270.50012)" fill="black"><tspan font-family="Arial"
font-size="11" font-weight="500" x="1.2138653" y="10" text
Length="41.572266">keystore</tspan></text></g><g id="id8_Graphic"><rect
x="17.000002" y="297.00012" width="54" height="31" fill="white"/><rect
x="17.000002" y="297.00012" width="54" height="31" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(22 306.50012)" fill="black"><tspan font-family="Arial"
font-size="11" font-weight="500" x="10.9973125" y="10"
textLength="22.005371">CRL</tspan></text></g><line x1="433.5" y1="192.00012"
x2="359.4" y2="192.00012" marker-end="url(#FilledArrow_Marker)" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><line
x1="294.5" y1="192.00012" x2="220.4" y2="192.00012"
marker-end="url(#FilledArrow_Marker)" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><line x1="145.60001" y1="192.00012"
x2="71.5" y2="192.00012" marker-start="url(#FilledArrow_Marker_2)"
stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><g id=
"id14_Graphic"><rect x="225.5" y="30.000122" width="54" height="31"
fill="white"/><rect x="225.5" y="30.000122" width="54" height="31"
stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(230.5 39.500122)"
fill="black"><tspan font-family="Arial" font-size="11" font-weight="500"
x="14.359617" y="10" textLength="15.280762">DP</tspan></text></g><g
id="id17_Graphic"><path d="M 59 246.65407 C 59 244.20372 58.619 243.90056
55.8359 241.47556 L 55.8065 241.45047 C 53.008698 239.00012 52.9796 239.00012
50.1083 239.00012 C 46.2851 239.00012 29 239.00012 29 239.00012 L 29 264.86679
L 59 264.86679 L 59 246.65407 Z" fill="white"/><path d="M 59 246.65407 C 59
244.20372 58.619 243.90056 55.8359 241.47556 L 55.8065 241.45047 C 53.008698
239.00012 52.9796 239.00012 50.1083 239.00012 C 46.2851 239.00012 29 239.00012
29 239.00012 L 29 264.86679 L 59 264.86679 L 59 246.65407 Z M 59 246.52785 C 59
244.20372 58.9706 244.20372 52.9796 244.20372 L 52.97
96 244.20372 C 52.9796 239.02547 52.9796 239.00012 50.2841 239.00012"
stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(34 245.93346)" fill="black"><tspan
font-family="Arial" font-size="11" font-weight="500" x="2.6604004" y="10"
textLength="14.679199">uid</tspan></text></g><g id="id19_Graphic"><path d="M
429 371.65408 C 429 369.20374 428.619 368.90057 425.8359 366.47559 L 425.8065
366.4505 C 423.0087 364.00012 422.97961 364.00012 420.1083 364.00012 C 416.2851
364.00012 399 364.00012 399 364.00012 L 399 389.86682 L 429 389.86682 L 429
371.65408 Z" fill="white"/><path d="M 429 371.65408 C 429 369.20374 428.619
368.90057 425.8359 366.47559 L 425.8065 366.4505 C 423.0087 364.00012 422.97961
364.00012 420.1083 364.00012 C 416.2851 364.00012 399 364.00012 399 364.00012 L
399 389.86682 L 429 389.86682 L 429 371.65408 Z M 429 371.52786 C 429 369.20374
428.9706 369.20374 422.97961 369.20374 L 422.97961 369.20374 C 422.97961
364.02548 4
22.97961 364.00012 420.2841 364.00012" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(404
364.93347)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="8.471924" y="10" textLength="6.1123047">t </tspan><tspan
font-family="Arial" font-size="11" font-weight="500" x="2.3596191" y="22"
textLength="15.280762">CA</tspan></text></g><g id="id20_Graphic"><path d="M
267.5 371.65408 C 267.5 369.20374 267.11899 368.90057 264.3359 366.47559 L
264.30649 366.4505 C 261.5087 364.00012 261.47961 364.00012 258.6083 364.00012
C 254.7851 364.00012 237.5 364.00012 237.5 364.00012 L 237.5 389.86682 L 267.5
389.86682 L 267.5 371.65408 Z" fill="white"/><path d="M 267.5 371.65408 C 267.5
369.20374 267.11899 368.90057 264.3359 366.47559 L 264.30649 366.4505 C
261.5087 364.00012 261.47961 364.00012 258.6083 364.00012 C 254.7851 364.00012
237.5 364.00012 237.5 364.00012 L 237.5 389.86682 L 267.5 389.86682 L 267.5
371.65408 Z
M 267.5 371.52786 C 267.5 369.20374 267.47061 369.20374 261.47961 369.20374 L
261.47961 369.20374 C 261.47961 364.02548 261.47961 364.00012 258.78409
364.00012" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(242.5 364.93347)"
fill="black"><tspan font-family="Arial" font-size="11" font-weight="500"
x="7.25" y="10" textLength="8.5561523">s </tspan><tspan font-family="Arial"
font-size="11" font-weight="500" x="2.3596191" y="22"
textLength="15.280762">CA</tspan></text></g><g id="id21_Graphic"><path d="M 106
371.65408 C 106 369.20374 105.619003 368.90057 102.8359 366.47559 L 102.806503
366.4505 C 100.0087 364.00012 99.9796 364.00012 97.1083 364.00012 C 93.285103
364.00012 76 364.00012 76 364.00012 L 76 389.86682 L 106 389.86682 L 106
371.65408 Z" fill="white"/><path d="M 106 371.65408 C 106 369.20374 105.619003
368.90057 102.8359 366.47559 L 102.806503 366.4505 C 100.0087 364.00012 99.9796
364.00012 97.1083 364.00012 C 93.285103
364.00012 76 364.00012 76 364.00012 L 76 389.86682 L 106 389.86682 L 106
371.65408 Z M 106 371.52786 C 106 369.20374 105.970596 369.20374 99.9796
369.20374 L 99.9796 369.20374 C 99.9796 364.02548 99.9796 364.00012 97.284103
364.00012" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(81 364.93347)" fill="black"><tspan
font-family="Arial" font-size="11" font-weight="500" x="6.941162" y="10"
textLength="9.173828">u </tspan><tspan font-family="Arial" font-size="11"
font-weight="500" x="2.3596191" y="22"
textLength="15.280762">CA</tspan></text></g><g id="id22_Graphic"><path d="M
267.5 441.65408 C 267.5 439.20374 267.11899 438.90057 264.3359 436.47559 L
264.30649 436.4505 C 261.5087 434.00012 261.47961 434.00012 258.6083 434.00012
C 254.7851 434.00012 237.5 434.00012 237.5 434.00012 L 237.5 459.86682 L 267.5
459.86682 L 267.5 441.65408 Z" fill="white"/><path d="M 267.5 441.65408 C 267.5
439.20374 267.11899 438.90057 264.3359 436.4
7559 L 264.30649 436.4505 C 261.5087 434.00012 261.47961 434.00012 258.6083
434.00012 C 254.7851 434.00012 237.5 434.00012 237.5 434.00012 L 237.5
459.86682 L 267.5 459.86682 L 267.5 441.65408 Z M 267.5 441.52786 C 267.5
439.20374 267.47061 439.20374 261.47961 439.20374 L 261.47961 439.20374 C
261.47961 434.02548 261.47961 434.00012 258.78409 434.00012" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(242.5 440.93347)" fill="black"><tspan font-family="Arial"
font-size="11" font-weight="500" x="2.3596191" y="10"
textLength="15.280762">CA</tspan></text></g><g id="id23_Graphic"><rect x="156"
y="261.00012" width="54" height="31" fill="white"/><rect x="156" y="261.00012"
width="54" height="31" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(161
270.50012)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="1.2138653" y="10" textLength="41.572266">k
eystore</tspan></text></g><g id="id24_Graphic"><rect x="156" y="297.00012"
width="54" height="31" fill="white"/><rect x="156" y="297.00012" width="54"
height="31" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(161 306.50012)"
fill="black"><tspan font-family="Arial" font-size="11" font-weight="500"
x="10.9973125" y="10" textLength="22.005371">CRL</tspan></text></g><g
id="id25_Graphic"><rect x="295" y="261.00012" width="54" height="31"
fill="white"/><rect x="295" y="261.00012" width="54" height="31" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(300 270.50012)" fill="black"><tspan font-family="Arial"
font-size="11" font-weight="500" x="1.2138653" y="10"
textLength="41.572266">keystore</tspan></text></g><g id="id26_Graphic"><rect
x="295" y="297.00012" width="54" height="31" fill="white"/><rect x="295"
y="297.00012" width="54" height="31" stroke="black" stroke-linecap=
"round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(300 306.50012)" fill="black"><tspan font-family="Arial"
font-size="11" font-weight="500" x="10.9973125" y="10"
textLength="22.005371">CRL</tspan></text></g><g id="id27_Graphic"><rect x="434"
y="261.00012" width="54" height="31" fill="white"/><rect x="434" y="261.00012"
width="54" height="31" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(439
270.50012)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="1.2138653" y="10"
textLength="41.572266">keystore</tspan></text></g><g id="id28_Graphic"><rect
x="434" y="297.00012" width="54" height="31" fill="white"/><rect x="434"
y="297.00012" width="54" height="31" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(439
306.50012)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="10.9973125" y="10" textL
ength="22.005371">CRL</tspan></text></g><g id="id29_Graphic"><path d="M 198
246.65407 C 198 244.20372 197.619 243.90056 194.83591 241.47556 L 194.8065
241.45047 C 192.0087 239.00012 191.9796 239.00012 189.10831 239.00012 C
185.2851 239.00012 168 239.00012 168 239.00012 L 168 264.86679 L 198 264.86679
L 198 246.65407 Z" fill="white"/><path d="M 198 246.65407 C 198 244.20372
197.619 243.90056 194.83591 241.47556 L 194.8065 241.45047 C 192.0087 239.00012
191.9796 239.00012 189.10831 239.00012 C 185.2851 239.00012 168 239.00012 168
239.00012 L 168 264.86679 L 198 264.86679 L 198 246.65407 Z M 198 246.52785 C
198 244.20372 197.9706 244.20372 191.9796 244.20372 L 191.9796 244.20372 C
191.9796 239.02547 191.9796 239.00012 189.2841 239.00012" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(173 245.93346)" fill="black"><tspan font-family="Arial"
font-size="11" font-weight="500" x="2.9692383" y="10"
textLength="14.0615234">sid</tspan>
</text></g><line x1="252.5" y1="433.50012" x2="252.5" y2="390.36682"
stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"
stroke-dasharray="1,4"/><line x1="237.04124" y1="440.23306" x2="106.45878"
y2="383.63388" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1" stroke-dasharray="1,4"/><line x1="267.90308" y1="440.2572"
x2="398.54123" y2="383.63388" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1" stroke-dasharray="1,4"/><line
x1="85.96109" y1="363.5321" x2="49.03891" y2="265.33484" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"
stroke-dasharray="1,4"/><line x1="245.06609" y1="363.56314" x2="190.4339"
y2="265.30377" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1" stroke-dasharray="1,4"/><line x1="259.92987" y1="363.5704"
x2="314.5661" y2="265.30377" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1" stroke-dash
array="1,4"/><line x1="418.88837" y1="363.5304" x2="456.11166" y2="261.46985"
stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"
stroke-dasharray="1,4"/><g id="id16_Graphic"><path d="M 337 246.65407 C 337
244.20372 336.61899 243.90056 333.8359 241.47556 L 333.80649 241.45047 C
331.0087 239.00012 330.97961 239.00012 328.1083 239.00012 C 324.2851 239.00012
307 239.00012 307 239.00012 L 307 264.86679 L 337 264.86679 L 337 246.65407 Z"
fill="white"/><path d="M 337 246.65407 C 337 244.20372 336.61899 243.90056
333.8359 241.47556 L 333.80649 241.45047 C 331.0087 239.00012 330.97961
239.00012 328.1083 239.00012 C 324.2851 239.00012 307 239.00012 307 239.00012 L
307 264.86679 L 337 264.86679 L 337 246.65407 Z M 337 246.52785 C 337 244.20372
336.97061 244.20372 330.97961 244.20372 L 330.97961 244.20372 C 330.97961
239.02547 330.97961 239.00012 328.28409 239.00012" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text
transform="tran
slate(312 245.93346)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="2.9692383" y="10"
textLength="14.0615234">sid</tspan></text></g><g id="id15_Graphic"><path d="M
476 242.7874 C 476 240.33705 475.619 240.03389 472.8359 237.60889 L 472.8065
237.5838 C 470.0087 235.13345 469.97961 235.13345 467.1083 235.13345 C 463.2851
235.13345 446 235.13345 446 235.13345 L 446 261.00012 L 476 261.00012 L 476
242.7874 Z" fill="white"/><path d="M 476 242.7874 C 476 240.33705 475.619
240.03389 472.8359 237.60889 L 472.8065 237.5838 C 470.0087 235.13345 469.97961
235.13345 467.1083 235.13345 C 463.2851 235.13345 446 235.13345 446 235.13345 L
446 261.00012 L 476 261.00012 L 476 242.7874 Z M 476 242.66118 C 476 240.33705
475.9706 240.33705 469.97961 240.33705 L 469.97961 240.33705 C 469.97961
235.1588 469.97961 235.13345 467.2841 235.13345" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(451 242.06679)" fill="black"
><tspan font-family="Arial" font-size="11" font-weight="500" x="4.191162"
>y="10" textLength="11.617676">tid</tspan></text></g><line x1="55.251965"
>y1="240.30643" x2="102" y2="192.00012" stroke="black" stroke-linecap="round"
>stroke-linejoin="round" stroke-width="1" stroke-dasharray="1,4"/><line
>x1="170.35509" y1="238.63782" x2="126" y2="192.00012" stroke="black"
>stroke-linecap="round" stroke-linejoin="round" stroke-width="1"
>stroke-dasharray="1,4"/><line x1="193.6956" y1="239.83868" x2="236"
>y2="192.00012" stroke="black" stroke-linecap="round" stroke-linejoin="round"
>stroke-width="1" stroke-dasharray="1,4"/><line x1="310.45096" y1="238.62245"
>x2="270" y2="192.00012" stroke="black" stroke-linecap="round"
>stroke-linejoin="round" stroke-width="1" stroke-dasharray="1,4"/><line
>x1="332.57697" y1="239.7428" x2="374" y2="192.00012" stroke="black"
>stroke-linecap="round" stroke-linejoin="round" stroke-width="1"
>stroke-dasharray="1,4"/><line x1="450.30655" y1="234.74352" x2="416"
>y2="192.00012
" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1" stroke-dasharray="1,4"/><line x1="137.08223" y1="161.27817"
x2="147.35626" y2="168.15216" marker-end="url(#FilledArrow_Marker)"
stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><line x1="89.917763" y1="161.27817" x2="79.643745"
y2="168.15215" marker-end="url(#FilledArrow_Marker)" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><line
x1="276.08224" y1="161.27817" x2="286.35626" y2="168.15215"
marker-end="url(#FilledArrow_Marker)" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><line x1="210.41556" y1="173.65733"
x2="228.91777" y2="161.27817" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><line x1="263.95541" y1="111.405846"
x2="294.7078" y2="154.10519" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><line x1="241.04457" y1="111.405846"
x2="216.077
91" y2="146.07178" marker-end="url(#FilledArrow_Marker)" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><g
id="id43_Graphic"><rect x="225.5" y="130.00012" width="54" height="31"
fill="white"/><rect x="225.5" y="130.00012" width="54" height="31"
stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(230.5 133.50012)"
fill="black"><tspan font-family="Arial" font-size="11" font-weight="500"
x="7.3234844" y="10" textLength="32.40918">object </tspan><tspan
font-family="Arial" font-size="11" font-weight="500" x="10.9919415" y="22"
textLength="22.016113">repo</tspan></text></g><g id="id51_Graphic"><rect
x="86.5" y="80.00012" width="54" height="31" fill="white"/><rect x="86.5"
y="80.00012" width="54" height="31" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(91.5
89.50012)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x=
"2.7338848" y="10" textLength="38.532227">auditlog</tspan></text></g><line
x1="380.04459" y1="111.405846" x2="355.07791" y2="146.07179"
marker-end="url(#FilledArrow_Marker)" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><line x1="102.04458" y1="111.405846"
x2="77.07792" y2="146.07178" marker-end="url(#FilledArrow_Marker)"
stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><line x1="155.70779" y1="154.10518" x2="124.95542"
y2="111.405846" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><line x1="433.7078" y1="154.10519" x2="402.95541"
y2="111.405846" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><g id="id12_Graphic"><rect x="86.5" y="130.00012" width="54"
height="31" fill="white"/><rect x="86.5" y="130.00012" width="54" height="31"
stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(91.5 133.50012)" fil
l="black"><tspan font-family="Arial" font-size="11" font-weight="500"
x="7.3234844" y="10" textLength="32.40918">object </tspan><tspan
font-family="Arial" font-size="11" font-weight="500" x="10.9919415" y="22"
textLength="22.016113">repo</tspan></text></g><g id="id56_Graphic"><rect
x="364.5" y="30.000122" width="54" height="31" fill="white"/><rect x="364.5"
y="30.000122" width="54" height="31" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(369.5
39.500122)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="14.359617" y="10"
textLength="15.280762">DP</tspan></text></g><line x1="207.96634"
y1="139.373245" x2="244.93245" y2="61.451866" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><line
x1="346.96634" y1="139.373245" x2="383.93246" y2="61.451866" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><line
x1="274.96887" y1="61.28758" x2="425.
49054" y2="167.04982" marker-end="url(#FilledArrow_Marker)" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><line
x1="399.06754" y1="61.451866" x2="431.79037" y2="130.42874"
marker-end="url(#FilledArrow_Marker)" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><g id="id50_Graphic"><rect x="364.5"
y="80.00012" width="54" height="31" fill="white"/><rect x="364.5" y="80.00012"
width="54" height="31" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(369.5
89.50012)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="2.7338848" y="10"
textLength="38.532227">auditlog</tspan></text></g><g id="id13_Graphic"><rect
x="225.5" y="80.00012" width="54" height="31" fill="white"/><rect x="225.5"
y="80.00012" width="54" height="31" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(230.5
89.50012)" fil
l="black"><tspan font-family="Arial" font-size="11" font-weight="500"
x="2.7338848" y="10" textLength="38.532227">auditlog</tspan></text></g><g
id="id61_Graphic"><path d="M 252.5 13.000244 L 282.5 13.000244 L 282.5 33.69358
C 273.5 31.106913 261.5 41.45358 252.5 36.280247 Z" fill="white"/><path d="M
252.5 13.000244 L 282.5 13.000244 L 282.5 33.69358 C 273.5 31.106913 261.5
41.45358 252.5 36.280247 Z" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(257.5
18.640244)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="2.9692383" y="10"
textLength="14.0615234">sid</tspan></text></g><g id="id62_Graphic"><path d="M
85.5 158.00018 L 115.5 158.00018 L 115.5 178.69351 C 106.5 176.10686 94.5
186.45352 85.5 181.28018 Z" fill="white"/><path d="M 85.5 158.00018 L 115.5
158.00018 L 115.5 178.69351 C 106.5 176.10686 94.5 186.45352 85.5 181.28018 Z"
stroke="black" stroke-linecap="round" stroke-linejoin="round" strok
e-width="1"/><text transform="translate(90.5 163.64018)" fill="black"><tspan
font-family="Arial" font-size="11" font-weight="500" x="2.6604004" y="10"
textLength="14.679199">uid</tspan></text></g><g id="id63_Graphic"><path d="M
114 64.000183 L 144 64.000183 L 144 84.69352 C 135 82.10685 123 92.45352 114
87.28018 Z" fill="white"/><path d="M 114 64.000183 L 144 64.000183 L 144
84.69352 C 135 82.10685 123 92.45352 114 87.28018 Z" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(119 69.640182)" fill="black"><tspan font-family="Arial"
font-size="11" font-weight="500" x="4.191162" y="10"
textLength="11.617676">tid</tspan></text></g><g id="id64_Graphic"><path d="M
252.5 64.000183 L 282.5 64.000183 L 282.5 84.69352 C 273.5 82.10685 261.5
92.45352 252.5 87.28018 Z" fill="white"/><path d="M 252.5 64.000183 L 282.5
64.000183 L 282.5 84.69352 C 273.5 82.10685 261.5 92.45352 252.5 87.28018 Z"
stroke="black" stroke-linecap="round" stroke-l
inejoin="round" stroke-width="1"/><text transform="translate(257.5 69.640182)"
fill="black"><tspan font-family="Arial" font-size="11" font-weight="500"
x="4.191162" y="10" textLength="11.617676">tid</tspan></text></g><g
id="id65_Graphic"><path d="M 392.5 64.000183 L 422.5 64.000183 L 422.5 84.69352
C 413.5 82.10685 401.5 92.45352 392.5 87.28018 Z" fill="white"/><path d="M
392.5 64.000183 L 422.5 64.000183 L 422.5 84.69352 C 413.5 82.10685 401.5
92.45352 392.5 87.28018 Z" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(397.5
69.640182)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="4.191162" y="10"
textLength="11.617676">tid</tspan></text></g><g id="id66_Graphic"><path d="M
222.5 158.00018 L 252.5 158.00018 L 252.5 178.69351 C 243.5 176.10686 231.5
186.45352 222.5 181.28018 Z" fill="white"/><path d="M 222.5 158.00018 L 252.5
158.00018 L 252.5 178.69351 C 243.5 176.10686 231.5 186.45352 222.5 181.
28018 Z" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(227.5 163.64018)"
fill="black"><tspan font-family="Arial" font-size="11" font-weight="500"
x="2.6604004" y="10" textLength="14.679199">uid</tspan></text></g><g
id="id67_Graphic"><path d="M 392.5 13.000244 L 422.5 13.000244 L 422.5 33.69358
C 413.5 31.106913 401.5 41.45358 392.5 36.280247 Z" fill="white"/><path d="M
392.5 13.000244 L 422.5 13.000244 L 422.5 33.69358 C 413.5 31.106913 401.5
41.45358 392.5 36.280247 Z" stroke="black" stroke-linecap="round"
stroke-linejoin="round" stroke-width="1"/><text transform="translate(397.5
18.640244)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="2.9692383" y="10"
textLength="14.0615234">sid</tspan></text></g><g id="id68_Graphic"><path d="M
469 382.00018 L 499 382.00018 L 499 402.69354 C 490 400.10687 478 410.45352 469
405.28021 Z" fill="white"/><path d="M 469 382.00018 L 499 382.00018 L 499
402.69354
C 490 400.10687 478 410.45352 469 405.28021 Z" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(474 387.6402)" fill="black"><tspan font-family="Arial"
font-size="11" font-weight="500" x="5.4157715" y="10"
textLength="9.168457">...</tspan></text></g><g id="id69_Graphic"><path d="M 499
422.65402 C 499 420.20367 498.619 419.90051 495.8359 417.47552 L 495.8065
417.45044 C 493.0087 415.00006 492.9796 415.00006 490.1083 415.00006 C 486.2851
415.00006 469 415.00006 469 415.00006 L 469 440.86676 L 499 440.86676 L 499
422.65402 Z" fill="white"/><path d="M 499 422.65402 C 499 420.20367 498.619
419.90051 495.8359 417.47552 L 495.8065 417.45044 C 493.0087 415.00006 492.9796
415.00006 490.1083 415.00006 C 486.2851 415.00006 469 415.00006 469 415.00006 L
469 440.86676 L 499 440.86676 L 499 422.65402 Z M 499 422.5278 C 499 420.20367
498.9706 420.20367 492.9796 420.20367 L 492.9796 420.20367 C 492.9796 415.02542
492.9796 415.00006 490.2841 4
15.00006" stroke="black" stroke-linecap="round" stroke-linejoin="round"
stroke-width="1"/><text transform="translate(474 421.9334)" fill="black"><tspan
font-family="Arial" font-size="11" font-weight="500" x="5.4157715" y="10"
textLength="9.168457">...</tspan></text></g><g id="id70_Graphic"><path d="M 474
453.00006 L 494 453.00006 C 496.7614 453.00006 499 455.23865 499 458.00006 L
499 473.86676 C 499 476.62817 496.7614 478.86676 494 478.86676 L 474 478.86676
C 471.2386 478.86676 469 476.62817 469 473.86676 C 469 473.86676 469 473.86676
469 473.86676 L 469 458.00006 C 469 455.23865 471.2386 453.00006 474 453.00006
Z" fill="white"/><path d="M 474 453.00006 L 494 453.00006 C 496.7614 453.00006
499 455.23865 499 458.00006 L 499 473.86676 C 499 476.62817 496.7614 478.86676
494 478.86676 L 474 478.86676 C 471.2386 478.86676 469 476.62817 469 473.86676
C 469 473.86676 469 473.86676 469 473.86676 L 469 458.00006 C 469 455.23865
471.2386 453.00006 474 453.00006 Z" stroke="black" stroke-lineca
p="round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(474 459.9334)" fill="black"><tspan font-family="Arial"
font-size="11" font-weight="500" x="5.4157715" y="10"
textLength="9.168457">...</tspan></text></g><g id="id71_Graphic"><rect x="469"
y="486.00006" width="30" height="25.866699" fill="white"/><rect x="469"
y="486.00006" width="30" height="25.866699" stroke="black"
stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text
transform="translate(474 492.9334)" fill="black"><tspan font-family="Arial"
font-size="11" font-weight="500" x="5.4157715" y="10"
textLength="9.168457">...</tspan></text></g><text transform="translate(513.5
388.93353)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="0" y="10"
textLength="45.251465">signature</tspan></text><text transform="translate(512.5
420.50006)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="0" y="10" textLength="47.072266">certificate</tspan></t
ext><text transform="translate(513.5 458.50006)" fill="black"><tspan
font-family="Arial" font-size="11" font-weight="500" x="0" y="10"
textLength="24.470703">node</tspan></text><text transform="translate(513.5
492.9334)" fill="black"><tspan font-family="Arial" font-size="11"
font-weight="500" x="0" y="10"
textLength="54.41455">information</tspan></text></g></g></svg>
Propchange: ace/site/trunk/content/docs/design/security-analysis-flow.svg
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: ace/site/trunk/content/docs/design/security-analysis-flow.svg
------------------------------------------------------------------------------
svn:mime-type = text/xml
Added: ace/site/trunk/content/docs/design/security-analysis.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/design/security-analysis.mdtext?rev=1641589&view=auto
==============================================================================
--- ace/site/trunk/content/docs/design/security-analysis.mdtext (added)
+++ ace/site/trunk/content/docs/design/security-analysis.mdtext Tue Nov 25
11:48:16 2014
@@ -0,0 +1,88 @@
+Title: Security Analysis
+
+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.
+
+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).
+
+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.
+
+Threat Scenarios
+================
+
+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.
+
+1. (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.
+2. 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.
+3. 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).
+4. 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.
+5. 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).
+
+Countermeasures
+===============
+
+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 working a
round 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.
+
+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.
+
+### Authentication
+
+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.
+
+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.
+
+### Authorization
+
+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.
+
+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).
+
+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.
+
+### Integrity
+
+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.
+
+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.
+
+Furthermore, taking into account relay servers the trusted certificates can be
limited further to for example only allow the actual server certificate.
+
+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.
+
+### Non Repudiation
+
+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.
+
+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).
+
+Furthermore, it will be easy to invalidate data from compromised entities by
adding their certificates to the certificate revocation list.
+
+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.
+
+### Confidentiality
+
+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.
+
+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.
+
+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.
+
+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).
+
+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.
+
+### Encryption
+
+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.
+
+Certificate based Flow Analysis
+===============================
+
+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.
+
+<object data="security-analysis-flow.svg" type="image/svg+xml" class="span12"
height="868"></object>
+
+Conclusion
+==========
+
+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.
+
Propchange: ace/site/trunk/content/docs/design/security-analysis.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Added: ace/site/trunk/content/docs/design/src/security-analysis-flow.graffle
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/design/src/security-analysis-flow.graffle?rev=1641589&view=auto
==============================================================================
Binary file - no diff available.
Propchange:
ace/site/trunk/content/docs/design/src/security-analysis-flow.graffle
------------------------------------------------------------------------------
svn:mime-type = application/xml
Added: ace/site/trunk/content/docs/design/template-mechanism.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/design/template-mechanism.mdtext?rev=1641589&view=auto
==============================================================================
--- ace/site/trunk/content/docs/design/template-mechanism.mdtext (added)
+++ ace/site/trunk/content/docs/design/template-mechanism.mdtext Tue Nov 25
11:48:16 2014
@@ -0,0 +1,36 @@
+Title: Template Mechanism
+
+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.
+
+The customization will be done when a new version is created, i.e., on call of
`approve()` 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.
+
+Proposed design
+===============
+
+In addition to the interfaces ArtifactHelper and ArtifactRecognizer, we
introduce a ArtifactPreprocessor, which has a single method
`preprocess(ArtifactObject object, Properties props)`, 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 `getPreprocessor()`, which returns an instance
of the preprocessor to be used for the type of artifact this helper helps.
+
+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, `getPreprocessor`
should return null).
+
+### Customization information
+
+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.
+
+This way, the Velocity template can use syntax like
+
+ #foreach( $license in $gateway.children)
+ #if ($license.attributes.vendor=="luminis")
+ Default license by luminis
+ #else
+ Custom license by $license.attributes.vendor
+ #end
+ #end
+
+### Support for remoting
+
+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.
+
+### On the 'needsApprove' state in the StatefulTargetObject
+
+With the mechanism above, `determineStoreState` 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.
+
Propchange: ace/site/trunk/content/docs/design/template-mechanism.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Modified: ace/site/trunk/content/docs/index.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/index.mdtext?rev=1641589&r1=1641588&r2=1641589&view=diff
==============================================================================
--- ace/site/trunk/content/docs/index.mdtext (original)
+++ ace/site/trunk/content/docs/index.mdtext Tue Nov 25 11:48:16 2014
@@ -34,8 +34,6 @@ Resources that go into more detail on us
guide](user-management-guide.html);
* adding support for new types of artifacts is described in [custom artifact
type
documentation](adding-custom-artifact-types.html);
-* if you are interested about the various roles and terminology used in Apache
ACE, read
- [roles and terminology page](ace-roles.html);
* to handle a large number of targets, you can make use of [intermediate relay
servers](configuring-relay-servers.html);
* configuring HTTP Basic authentication in ACE is described in the
[authentication
@@ -44,6 +42,8 @@ Resources that go into more detail on us
certificates](using-client-certificates.html);
* various deployment strategies for Apache ACE are described in the [ACE
deployment
strategies document](ace-deployment-strategies.html);
+* if you are interested in performing load tests, or want to get started with
automating
+ ACE deployments, read all about it in our [test script
document](test-script.html);
## Developing for Apache ACE
@@ -64,18 +64,9 @@ There are several resources available on
## Background information, designs and analysis
-* if you are interested in performing load tests, or want to get started with
automating
- ACE deployments, read all about it in our [test script
- document](test-script.html);
+* if you are interested about the various roles and terminology used in Apache
ACE, read
+ [roles and terminology page](ace-roles.html);
* various use cases are described on the [use cases page](use-cases);
-* detailed analysis documentation giving background information on some
development
- principles currently used:
- - [audit log analysis](analysis/auditlog-analysis.html);
- - [bundle repository analysis](analysis/bundlerepository-analysis.html);
- - [security analysis](analysis/security-analysis.html);
- - [template mechanism](analysis/template-mechanism.html).
-* detailed design documentation:
- - [authentication design](design/authentication-design.html);
- - [remote interface design](design/remote-interfaces.html);
- - [audit log details](design/auditlog-protocol.html);
+* to get more details on the why and how of certain parts of ACE can be found
in the
+ [design and analysis documentation](design/index.html).
