Package net.jini.security.proxytrust

Defines a trust verifier to support verification of proxies that use dynamically downloaded code, implementation mechanisms to support the verification of such proxies, and an exporter for remote objects that have such proxies.

See: Description

Interface Summary

Interface	Description
ProxyTrust	Defines a remote interface for obtaining a proxy trust verifier.
ProxyTrustIterator	Defines an iterator that produces objects from which a TrustVerifier might be obtained.
ServerProxyTrust	Defines a local interface to obtain a proxy trust verifier.
TrustEquivalence	Defines an interface for checking that an object (that is not yet known to be trusted) is equivalent in trust, content, and function to a known trusted object.
UntrustedObjectSecurityContext	A trust verifier context element that provides a security context to use to restrict privileges when invoking methods on untrusted objects.

Class Summary

Class	Description
BasicUntrustedObjectSecurityContext	A basic trust verifier context element that provides a security context to use to restrict privileges when invoking methods on untrusted objects, based on a specified set of permissions.
ProxyTrustExporter	Contains the information necessary to export a remote object that has a proxy that will not directly be considered trusted by clients, such that the proxy can be trusted by clients using ProxyTrustVerifier.
ProxyTrustInvocationHandler	Invocation handler for remote objects, supporting proxy trust verification by clients using ProxyTrustVerifier.
ProxyTrustVerifier	Trust verifier for service proxies that use dynamically downloaded code.
SingletonProxyTrustIterator	A simple ProxyTrustIterator that produces a single object as the only element of the iteration.

Package net.jini.security.proxytrust Description

Defines a trust verifier to support verification of proxies that use dynamically downloaded code, implementation mechanisms to support the verification of such proxies, and an exporter for remote objects that have such proxies. The trust verifier is intended to be specified in a resource to configure the operation of Security.verifyObjectTrust.

The purpose of this package is to support verification of proxies that use dynamically downloaded code, in a way that limits the knowledge that must be pre-configured into the client. Specifically, the idea is to require the client to only know who the server must authenticate as (which is something the client presumably needs to know anyway), to avoid requiring the client to know anything else (such as where the code was downloaded from or who signed that code), and to avoid making assumptions about the authentication mechanism (such as requiring the server to have a public/private key pair that it has to use for signing the proxy code).

Rather than having the client directly determine if it trusts the proxy, the approach taken is to first determine that the client can trust the server (by requiring the server to authenticate itself), and then determine that the server trusts the proxy (by asking the server for a verifier and passing the proxy to that verifier). If the client trusts the server and the server trusts the proxy, then transitively the client is inferred to trust the proxy. However, there are questions to answer for both of these steps.

First, there is the question of how the client can reliably verify that the server authenticates itself, when the client does not yet trust the downloaded proxy. The ProxyTrustVerifier requires the proxy to support some bootstrap remote communication mechanism that the client does trust. Specifically, the proxy must be able to provide a bootstrap proxy, which must be an instance of both ProxyTrust and RemoteMethodControl. This bootstrap proxy either must be trusted by the client, or it must be a dynamic proxy which is trusted by the client after removing remote codebase information from the dynamic proxy class. In the common case of a smart proxy wrapped around a standard dynamic proxy (for example, a dynamic proxy for a remote object exported to use Jini(TM) extensible remote invocation (Jini ERI)), the dynamic proxy usually can serve as the bootstrap proxy if its invocation handler does not depend on any downloaded code, on the assumption that the client will have configured in a trust verifier for local dynamic proxies and their invocation handlers (for example, net.jini.jeri.BasicJeriTrustVerifier). However, there is no requirement that normal communication with the server use the same protocol used by the bootstrap proxy; the bootstrap proxy could be used strictly for trust verification. The ProxyTrustExporter is provided for this purpose.

Second, there is the question of how to reliably obtain a verifier from the server. (The proxy is not sent to the server because an untrusted proxy could use a writeReplace serialization method to replace itself on the wire with a trusted proxy; the proxy needs to be checked in the client.) Authentication of the server should be required during the remote call through the bootstrap proxy to obtain the verifier from the server, as should object integrity, so that the remote call and the verifier object received from it can be trusted. To accomplish this, the client is responsible for specifying ServerAuthentication.YES, an appropriate ServerMinPrincipal instance, and Integrity.YES as requirements for the ProxyTrust.getProxyVerifier method in a MethodConstraints instance included as an element of the context collection passed to Security.verifyObjectTrust. Normally such constraints should be obtained from a Configuration rather than being explicitly constructed.

Since:

2.0

Version:

3.0