JEP 411: Why the last version to support SecurityManager is likely to be the most powerful version of Java.

[Peter Firmstone]

A disclaimer: I accept SecurityManager will be removed, but I feel a few 
words are in order before it's passing.

A little history:

> Pre-1994, Bill Joy presented a proposal to Sun Labs where he
> presented three main concepts:
> 1) a language that would run on all platforms,
> 2) a virtual machine to run this language, and
> 3) a networked system to allow the distributed virtual machines
> to work as a singular system.
> In 1995, the language and virtual machine were introduced to
> the market as the Java Programming language and Java Virtual
> Machine. The system context, however, was kept in the Sun R&D
> for continued research and development. This system context
> is Jini.
Reference: http://di002.edv.uniovi.es/~falvarez/whatisjini.pdf

This fit into Sun's vision: "The network is the computer."

The components of item 3 above, have presented significant technical 
challenges, progress having been made at various times during Java's 
history.  Only in recent years have all the pieces of the puzzle come to 
together to realize the original goal.

So it appears that Java 1.17 will remain an important version for many 
years to come.

There are two types of scalability, vertical and horizontal.

Various OS platforms that support different CPU and GPU architectures, 
clearly the vector API is an important component as are other recent 
improvements.

IPv6 enables end to end connectivity, rather than IPv4's publish 
subscribe, server client model and issues with NAT.  Web services are 
based on the publish subscribe model, with message passing. The Web 
services push API gives web applications the ability to listen to 
events. https://developer.mozilla.org/en-US/docs/Web/API/Push_API   But 
there remain issues with cross site request forgery's.

The glue is important too (which is what Jini is).

What are the key components:

 1. JVM's installed on each node.
 2. Dynamic class loading, with verification and type safety.
 3. Network end to end connectivity (IPv6 adoption is currently 32%)
 4. Privacy, Authentication and Identity.
 5. Object Serialization protocols (Java Serialization is flawed).
 6. Jini Extensible Remote Invocation (RMI isn't suitable due to class
    resolution issues and limited extensibility).
 7. Service architecture based on Interfaces.
 8. Dynamic network discovery (IPv6 global discovery only recently added
    https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml).
 9. Ability to "join" specific groups on the network.
10. Lookup services (multiple, it's a common misconception there is only
    one), to find services, as well as listeners to be notified when
    services are added, removed or changed.
11. Network Transaction Service.
12. A powerful Configuration, that uses Groovy.

Why wasn't Jini a huge success when it was released in 1998?

 1. It had some initial success, but class resolution was a big problem
    http://sorcersoft.org/resources/jini/smli_tr-2006-149.pdf as
    ClassLoader's added complexity that wasn't originally envisioned. 
    To solve this problem, instead of using RMIClassLoading for class
    resolution and visibility, ClassLoader's  are assigned at each
    Endpoint and are completely responsible for class visibility and
    resolution, so it works with non-hierarchical class loading systems
    like OSGi.
 2. Security wasn't added until 2002, combined with IPv4, it relegated
    Jini to private trusted networks, in the age of the internet,
    limiting it's appeal.  This is no longer the case.
 3. When Security was added, it had been assumed the Java Sandbox and
    Java Serialization were secure, so authentication of services was
    performed after class loading and de-serialization, ouch!
 4. The security model, added unnecessary complexity in the form of
    ProxyTrust  (This isn't used today).  We just authenticate first
    now, ensure the connection is private and validate the code, then
    let the code validate the input, to fail atomically, and this is
    handled for the user, all the user need do is configure their
    services to use TLS, and ensure their services runs with the login
    Subject.
 5. Objects were exported remotely via their constructors allowing
    "this" to escape, prior to the Java 1.5 JMM, this was changed, an
    interface called Startable allows services to be started after
    construction, the same thing happens with Activation (Phoenix, not
    RMI), which is basically a watchdog for services.

Sun later released Jini as open source under the Apache 2.0 license in 
2007 and donated it to Apache who renamed it to River.

Remaining issues have taken about 12 years to resolve, all up it's 
probably had 25 years of development.

http://nighthacks.com/jag/res/Fallacies.html

https://github.com/pfirmstone/JGDMS

If JAAS continues to function in later versions of Java, we will be able 
to support them as server side services, but not as clients, without 
SecurityManager, so it will always depend on the last version of Java 
that contains a fully functional SecurityManager.  Otherwise we fail the 
6th Fallacy of distributed computing.

Still have a couple of things left to do, such as support pack200 for 
smaller proxy code download sizes and update it to support Java 1.17 
bytecode as well as other support other object serialization protocols 
using the atomic Serialization API, it will be a configuration concern.

The original vision, it was visionary, but now it works, well it's more 
than that, it works really well.

-- 
Regards,
  
Peter.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210515/385e212a/attachment.htm>