Sergio,
Some additional notes:
1. Use the BasicJeriExporter (via your configuration) with the
SSLServerExporter and BasicILFactory
2. Look at the javadoc in the net.jini.jeri.ssl package, this
requires SSL certificates.
3. Set your constraints:
1. ConfidentialityStrength to strong.
2. Confidentiality to yes.
3. ClientAuthentication to yes.
4. Make sure DGC is disabled (it's insecure), you'll need to retain a
strong reference locally to your server, to keep your service
alive; so it doesn't get garbage collected after exporting.
If you grant permissions to your codebase signers (optionally you may
also configure it to be running with specific Principal's) then you
don't need to worry about proxy preparation and granting permissions
dynamically. Sufficient permissions for the proxy to contact the
server host will be granted automatically.
Regards,
Peter.
On 14/06/2015 3:36 PM, Peter wrote:
Hi Sergio,
No IIOP isn't the right solution, IIOP is designed for intra language
operability (eg C or C++) on local trusted networks.
Firstly there are some restrictions on internet communications due to
firewalls and NAT (network address translation):
1. Services (servers) must be visible, that is have a static IPv4
address or an IPv6 address that is globally visible on a known
port, or is a known port on a resolvable domain name address.
2. Services behind firewalls with NAT, must be assigned a port on the
firewall.
3. It is possible for clients behind firewalls to contact an internet
visible service, and be contacted by the service, but only after
the client has initiated communications, so for instance, clients
of javaspaces on separate private networks, may put and take from
an internet visible javaspace service.
If you want security, use secure unicast discovery, clients and
servers must be authenticated prior to any deserialization occurring,
see javadoc for the following packages or classes:
1. com.sun.jini.discovery.ssl
2. net.jini.discovery.ConstrainableLookupLocator
3. net.jini.discovery.LookupLocatorDiscovery
4. net.jini.core.constraint.ClientAuthentication
5. net.jini.core.constraint.ServerAuthentication
6. com.sun.jini.discovery.DiscoveryProtocolVersion (TWO)
When you configure your lookup service (Reggie), you must configure it
to always use client authentication, this strategy should also be
adopted for any other services you have.
Your also need to sign your codebase jar files.
Don't concern yourself too much with proxy trust, this is performed
after downloading, class loading and deserializing a proxy (too late),
the only way to ensure security, is to authenticate servers and
clients and sign codebases. Do not allow anyone to register their
services to your lookup service without authenticating.
Don't believe the outdated story that Reggie doesn't pose a security
risk, it's only secure if clients are always authenticated. If you
don't authenticate your clients, over a secure connection, then Reggie
is exposed to deserialization attacks.
For client security, make sure you always authenticate the lookup
service (during discovery), also install the
net.jini.loader.pref.RequireDLPermProvider and grant
net.jini.loader.DownloadPermission to your codebase signers.
With regards to proxy trust, I recently investigated fixing security
issues and developed a working prototype for community demonstration /
discussion (doing so would allow the establishment of a service
community where not all parties were known to each other and
authentication of clients wasn't always desired or required):
1. Input validation (similar to a web server validating html) of data
streamed to an ObjectInputStream, which ultimately involved the
replacement of the ObjectInputStream, to prevent deserialization
attacks (Constraint based).
2. Annotating jar files with permissions required by a service proxy
(least privilege principle), to be granted during proxy trust
establishment.
3. Inversion of responsibility during proxy trust establishment,
instead of performing untrusted class loading, for a smart proxy,
prior to asking it for a bootstrap proxy, then determining proxy
trust (too late). Instead, obtain the bootstrap proxy (local code
only, with input validation) and ask it for the smart proxy during
proxy trust verification, this also allows for delayed
unmarshalling during lookup and filtering on entry's locally,
before any codebase downloading is performed.
However the prototype wasn't well received, the community expressed
concern that River is well established on local networks and
discussing security and its problems on the internet creates a
perception that River is complex. My original plan was to first fix
security, then to create tools to streamline it.
There is an opportunity for River to remove proxy trust and simplify
security, which fits well with expressed concerns, for limited
internet connectivity (where all connections are securely
authenticated and the lookup service authenticates clients and all
clients know and trust each other), leaving proxy trust as is, without
fixing however, leaves security complicated superfluously.
So as I said, don't be too concerned about proxy trust; it doesn't
enhance security under current circumstances.
Regards,
Peter.
Hi, I have an client/server application using Apache River using the
BasicJeriExporter over tcp/ip. Now I have a requirement to use it across
the Internet (currently using local network). How could be it done? I
saw
Apache River can communicate using IIOP, would it be a good approach?
Has
someone tried to use Apache River over IIOP?
Thank you.
