OSGi & Configuration
Any OSGi people on this list have advice or experience with ensuring class visibility with Configuration files? AtomicILFactory accepts a class or ClassLoader argument, for a service, this is used to locate the ClassLoader of the proxy bundle for deserialization. A class can be passed in from a configuration file. Any experience with ensuring the class is visible to the configuration? We have two configuration providers, one Groovy based, the other the old legacy Java like syntax that only uses static methods and constructors. Thanks, Peter.
Re: Thoughts, progress and plans.
Hi Bryan, Yes, I'm hoping that it creates some renewed interest. River is currently limited to local networks and vpn's. So we'll be providing improved security options for developers using local networks, but also be able to completely lock down a public service that's reachable over https. Anyone with an IPv6 address, will be able to provide a service to clients also using IPv6, anywhere in the world over https and we're not going to have the IPv4 private network NAT issue. We'll need a few public lookup services available over https and people will be able to create their own. It's likely that multicast packets will be blocked by some networks, so unicast lookup over https is important to fill that gap. Once people have a link to at least one https lookup service, then they'll be able to search for other lookup services registered there to perform a far wider global search. Then we have delayed unmarshalling to allow local filtering to occur using logical operations before provisioning code. Cheers, Peter. On 20/04/2018 12:09 AM, Bryan Thompson wrote: Peter, That sounds like a quite a bit of interesting progress! Maybe we could brainstorm some examples of secure services on the list, implement some examples, and publish the services and their code? Bryan On Thu, Apr 19, 2018 at 5:19 AM, Peterwrote: What I’ve been up to: 1. Moved atomic serialization and support for OSGi into AtomicILFactory, so BasicILFactory functionality effectively remains unchanged. Taking advantage of the Extensible part of JERI. Note we can also support other protocols by taking advantage of JERI's extensibility. 2. Newly created TLS RMIServerSocketFactory and RMIClientSocketFactory utilise the current Subject for credentials to perform TLS handshakes and connections. This is allows the Registry to be secured for Phoenix, so Phoenix can run in secure mode, using JERI Secure endpoints for the ActivationSystem and other components and use the same LoginModule for both. SSL RMI socket factory's included with the jvm require access to a KeyStore and don't utilise the Subject. Note that a truststore is still required. Using the Subject is more flexible and it's extensible with LoginModule. a. JERI with secure sockets and atomic serialization can now be utilised for the following services in Phoenix: i. ActivationMonitor, ii. ActivationSystem, iii. Activator. b. RMI with TLS sockets for securing: i. Registry service ii. LocateRegistry methods. 3. Lots of additional testing using atomic endpoints over JSSE, transient and activatable configurations for tests. a. We currently have about 1400 tests, and this is being compounded to 5600 tests with each configuration (there’s more configuration options so this can go higher eventually). 1400 tests take about 24 hours to complete, so we’re talking 4 days’ worth of testing for a full run. 4. FindBugs Static testing and more bug fixes. I’m getting ready to fill out the modular build structure for River and populate it with River’s code. Next steps are then to donate externally developed features, module by module, so people can digest the changes and propose improvements they want too. I’m very close to being able to deploy a locked down secure version of Reggie with TLS and atomic serialization over IPv6, so we can have a public lookup service permanently running so people can register their services there, this will be locatable via https unicast and IPv6 Global multicast. We can then update and modernise the service browser, so people can experiment with these services. I’m also thinking we need to set up a small Certificate Authority, so any user can request a user certificate be signed, and service providers also. I think we should keep these separate, as users could remain relatively anonymous, client certificates are only required to prevent MITM attacks. Services will require more discretion as users will consume their code, so I think we need a reputation system, where services that behave badly can be identified and have their certificates revoked at a Hold level, or revoked irreversibly depending on whether they rectify the issue with their service. We could also have different CA signing certs that represent levels of trust, so you basically start with a minimal level of trust and as you build up your reputation, you get your certificate signed with CA signer cert that represents a higher level of trust. Services will be able to track client certificates, but don’t need to know any personal details, your private certificate will be your identity basically. So what I’m thinking is, we can create a service ecosystem, where we’re using secure TLS certificates, so companies / people can interact securely. Regards, Peter.
Re: Thoughts, progress and plans.
Peter, That sounds like a quite a bit of interesting progress! Maybe we could brainstorm some examples of secure services on the list, implement some examples, and publish the services and their code? Bryan On Thu, Apr 19, 2018 at 5:19 AM, Peterwrote: > What I’ve been up to: > > 1. Moved atomic serialization and support for OSGi into AtomicILFactory, so > BasicILFactory functionality effectively remains unchanged. Taking advantage > of the Extensible part of JERI. Note we can also support other protocols by > taking advantage of JERI's extensibility. > 2. Newly created TLS RMIServerSocketFactory and RMIClientSocketFactory > utilise the current Subject for credentials to perform TLS handshakes and > connections. This is allows the Registry to be secured for Phoenix, so > Phoenix can run in secure mode, using JERI Secure endpoints for the > ActivationSystem and other components and use the same LoginModule for both. > SSL RMI socket factory's included with the jvm require access to a KeyStore > and don't utilise the Subject. Note that a truststore is still required. > Using the Subject is more flexible and it's extensible with LoginModule. > a. JERI with secure sockets and atomic serialization can now be utilised for > the following services in Phoenix: > i. ActivationMonitor, > ii. ActivationSystem, > iii. Activator. > b. RMI with TLS sockets for securing: > i. Registry service > ii. LocateRegistry methods. > 3. Lots of additional testing using atomic endpoints over JSSE, transient > and activatable configurations for tests. > a. We currently have about 1400 tests, and this is being compounded to 5600 > tests with each configuration (there’s more configuration options so this > can go higher eventually). 1400 tests take about 24 hours to complete, so > we’re talking 4 days’ worth of testing for a full run. > 4. FindBugs Static testing and more bug fixes. > > I’m getting ready to fill out the modular build structure for River and > populate it with River’s code. > > Next steps are then to donate externally developed features, module by > module, so people can digest the changes and propose improvements they want > too. > > I’m very close to being able to deploy a locked down secure version of > Reggie with TLS and atomic serialization over IPv6, so we can have a public > lookup service permanently running so people can register their services > there, this will be locatable via https unicast and IPv6 Global multicast. > We can then update and modernise the service browser, so people can > experiment with these services. > > I’m also thinking we need to set up a small Certificate Authority, so any > user can request a user certificate be signed, and service providers also. I > think we should keep these separate, as users could remain relatively > anonymous, client certificates are only required to prevent MITM attacks. > Services will require more discretion as users will consume their code, so I > think we need a reputation system, where services that behave badly can be > identified and have their certificates revoked at a Hold level, or revoked > irreversibly depending on whether they rectify the issue with their service. > > We could also have different CA signing certs that represent levels of > trust, so you basically start with a minimal level of trust and as you build > up your reputation, you get your certificate signed with CA signer cert that > represents a higher level of trust. > > Services will be able to track client certificates, but don’t need to know > any personal details, your private certificate will be your identity > basically. > > So what I’m thinking is, we can create a service ecosystem, where we’re > using secure TLS certificates, so companies / people can interact securely. > > Regards, > > Peter.
Thoughts, progress and plans.
What I’ve been up to: 1. Moved atomic serialization and support for OSGi into AtomicILFactory, so BasicILFactory functionality effectively remains unchanged. Taking advantage of the Extensible part of JERI. Note we can also support other protocols by taking advantage of JERI's extensibility. 2. Newly created TLS RMIServerSocketFactory and RMIClientSocketFactory utilise the current Subject for credentials to perform TLS handshakes and connections. This is allows the Registry to be secured for Phoenix, so Phoenix can run in secure mode, using JERI Secure endpoints for the ActivationSystem and other components and use the same LoginModule for both. SSL RMI socket factory's included with the jvm require access to a KeyStore and don't utilise the Subject. Note that a truststore is still required. Using the Subject is more flexible and it's extensible with LoginModule. a. JERI with secure sockets and atomic serialization can now be utilised for the following services in Phoenix: i. ActivationMonitor, ii. ActivationSystem, iii. Activator. b. RMI with TLS sockets for securing: i. Registry service ii. LocateRegistry methods. 3. Lots of additional testing using atomic endpoints over JSSE, transient and activatable configurations for tests. a. We currently have about 1400 tests, and this is being compounded to 5600 tests with each configuration (there’s more configuration options so this can go higher eventually). 1400 tests take about 24 hours to complete, so we’re talking 4 days’ worth of testing for a full run. 4. FindBugs Static testing and more bug fixes. I’m getting ready to fill out the modular build structure for River and populate it with River’s code. Next steps are then to donate externally developed features, module by module, so people can digest the changes and propose improvements they want too. I’m very close to being able to deploy a locked down secure version of Reggie with TLS and atomic serialization over IPv6, so we can have a public lookup service permanently running so people can register their services there, this will be locatable via https unicast and IPv6 Global multicast. We can then update and modernise the service browser, so people can experiment with these services. I’m also thinking we need to set up a small Certificate Authority, so any user can request a user certificate be signed, and service providers also. I think we should keep these separate, as users could remain relatively anonymous, client certificates are only required to prevent MITM attacks. Services will require more discretion as users will consume their code, so I think we need a reputation system, where services that behave badly can be identified and have their certificates revoked at a Hold level, or revoked irreversibly depending on whether they rectify the issue with their service. We could also have different CA signing certs that represent levels of trust, so you basically start with a minimal level of trust and as you build up your reputation, you get your certificate signed with CA signer cert that represents a higher level of trust. Services will be able to track client certificates, but don’t need to know any personal details, your private certificate will be your identity basically. So what I’m thinking is, we can create a service ecosystem, where we’re using secure TLS certificates, so companies / people can interact securely. Regards, Peter.