JEP: 411 How JGDMS utilises the Java platform

[Peter Firmstone]

Something else that JERI does that RMI doesn't is transfer the Subject 
from a calling thread in one JVM to the thread invoked in another JVM, 
so you have user principles, and service principles mixing in numerous 
JVM, all while only granting the minimal permissions required to perform 
role / task.

On 30/05/2021 9:22 am, Peter Firmstone wrote:
>
> 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/5e1bc83f/attachment.htm>