net.jini.securityThe
net.jini.security package and its subpackages provide
abstractions and facilities for managing security.
A new proxy preparer class,
VerifyingProxyPreparer, has been added. In contrast to
BasicProxyPreparer, this new preparer always verifies that
proxies are trusted, and permits full control over the context elements used
during trust verification, the class loader used to find trust verifiers,
and the principals used to scope dynamic permission grants. In particular,
it can be used to specify a
BasicUntrustedObjectSecurityContext context element for
controlling the operation of
ProxyTrustVerifier (see below).
ProxyTrustVerifier has been changed so that, by default,
when attempting to obtain a bootstrap proxy, operations on untrusted objects
are performed in a restricted security context that limits the permissions
of unprivileged code (meaning code that does not use some form of
doPrivileged) to just the permissions that have been
granted to all code. In most cases this default will not cause problems,
but there are cases where it will. In particular, if you are trying to
verify a proxy that uses activation, and a remote call to activate the
service is required to obtain the bootstrap proxy, the remote call will
now fail due to lack of a SocketPermission (unless you have
granted broad connect SocketPermission to all code,
which is generally undesirable). To make such a deployment work, you need
to provide a
BasicUntrustedObjectSecurityContext context element that
specifies which additional permissions unprivileged code is permitted to
exercise (provided the code has already been granted those permissions).
This is aimed in particular at specifying the permissions that local code
(or already trusted code) is permitted to exercise. For example, you would
specify SocketPermission to connect to whatever hosts and ports
can be used for activation. You can use
VerifyingProxyPreparer (see above) to specify such a
context element.