<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>This is provided as information only I'm not looking for
arguments, debate or even requesting functionality, I'm just
documenting what JGDMS does now, unfortunately JGDMS appears to be
too entangled with current security API's at its foundations to be
easily migrated, I guess that will depend on the new API's, but it
might provide some insights into the next security architecture's
design. My fear is this JEP is focused on removal, more than
replacement.<br>
</p>
<p>There is no limit on the number of nodes that may participate,
nor the number of principals.<br>
</p>
<p>JGDMS is a service based architecture, these services are
discovered dynamically, I'm not going to go into the details of
discovery here, but instead to focus on the architecture of the
service and its components.</p>
<p>Firstly while the service itself is a "Server - Client" model,
the JVM's or compute nodes are peer to peer and doesn't directly
translate to a distinction between server and client compute
nodes, Swing is supported for graphical API's, it would also be
possible to use JavaFX also (untested).</p>
<p>When a node wants to participate, it discovers lookup services,
that belong to particular groups, these lookup services contain
services available, the node may register services with these
lookup services, and it may search for other services and utilise
them.<br>
</p>
<p>So back to focusing on the Service:</p>
<p>Below is a diagram of a service in a modular environment, where
Bundle is an OSGi module, but it could also be a JPMS module
(future version) for arguments sake. Here the COM link is a
remote invocation protocol, but may be any of a number of
protocols, the protocol can be replaced without modification to
the service implementation via configuration. It is possible make
use of, but doesn't require RMI or Java Serialization, any number
of protocols may be used. These are Remote Invocation protocols.
The most commonly used communication protocol is called JERI, or
Jini Extensible Remote Invocation, JGDMS provides a JERI
implementation with an Atomic Invocation Layer, where it supports
failure atomicity. <br>
</p>
<p>Unlike RMI, Atomic JERI assigns ClassLoader's at each endpoint
for class resolution and it doesn't append CodeSource URL's into
the stream.</p>
<p>Before the Client JVM can load the Proxy Bundle, it must first
designate a ClassLoader, this ClassLoader has an identity, which
is made up of, RFC3986 URI CodeSource's, The Servers Endpoint
identity (which includes the servers IPv6 address and the security
constraints made) and the type of connection used (eg TLS, or
Kerberos).</p>
<p>Permissions are granted statically using POLP, statically by
policy files (or remote policy services) to each ProtectionDomain,
based on CodeSource and Principals, and dynamically to the
ClassLoader of the ProxyBundle in the Client JVM, following server
and client authentication.</p>
<p>Different services may even use the same CodeSource, however
their classes are loaded by different ClassLoader's based on the
Server's identity and security constraints.</p>
<p>So while OpenJDK devs claim the ProtectionDomains on the stack
represent Code and Principles, we use it to represent the
difference services on the call stack, not code.</p>
<p>In our case spawning hundreds of processes to manage the
permissions of each service used by a client isn't practical.</p>
<p>I hope this helps people understand how we are using Java, this
is only scratching the service, we are not the only ones who do
this, I am aware of companies and military, who use POLP also.<br>
</p>
<pre><code> SERVER JVM
============================================================
______________
| |
| Service |
| API Bundle |
|______________|
|
|
Imports
API
Packages
|
|
____________________ ______|_______
| | Imports packages | |
| Service Bundle |<--------------------| Proxy Bundle |--SEP
| Implements | from proxy |______________| |
| Proxy API | |
|____________________| |
|
============================================================ |
|
|
|
C
O
CLIENT JVM M
============================================================ |
L
____________________ ______________ I
| | | | N
| Distribution | Imports packages | Service | K
| Provider |<--------------------| API Bundle | |
| Discovers & | from API |______________| |
| Registers service | | |
|____________________| | |
Imports |
API |
Packages |
| |
| |
______|_______ |
| | |
| Proxy Bundle |---EP
|______________|
============================================================
</code></pre>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone</pre>
</body>
</html>