JEP: 411 How JGDMS utilises the Java platform

[Peter Firmstone]

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.

There is no limit on the number of nodes that may participate, nor the 
number of principals.

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.

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).

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.

So back to focusing on the Service:

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.

Unlike RMI, Atomic JERI assigns ClassLoader's at each endpoint for class 
resolution and it doesn't append CodeSource URL's into the stream.

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).

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.

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.

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.

In our case spawning hundreds of processes to manage the permissions of 
each service used by a client isn't practical.

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.

|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 |______________| 
============================================================ |

-- 
Regards,
  
Peter Firmstone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210530/25a6f9d8/attachment.htm>