Many potential applications of Jini require network security. Although various third parties have made proprietary security extensions
to Jini, until now the only security available to users of the standard Jini release is the security infrastructure of the Java platform.
The Jini Community's Davis project is about to change that.
Bob Scheifler is leading the development of the next release of Jini, in which security is the central concern,
as part of the Davis project.

On Friday, April 12, 2002 Bill Venners visited the Sun Microsystems campus in
Burlington, Massachusettes and interviewed
Bob Scheifler, Sun Distinguished Engineer and architect in the Jini Group.
In Part I of this interview, Scheifler discusses the need for security in Jini and the special security considerations
of dynamically downloaded code.
In Part II, Scheifler describes the mechanisms used to determine whether a proxy should be trusted.
In Part III, Scheifler covers the mechanisms used to achieve object integrity.
In Part IV, Scheifler discusses security constraints and the RemoteSecurity interface.
In this fifth installment of the interview, Scheifler describes the dynamic granting of permissions to proxies.

Bob Scheifler: You have to decide if you trust the proxy, then you have to decide
what you will allow the proxy to do. That is the process of
authorization, where you grant permissions in the standard Java model.
You authorize by granting permissions. Somehow we have to grant the
proxy permissions dynamically.

We have to grant permissions dynamically for a couple of reasons. One
is that in the standard Java security model you grant permissions to a
code base or to URLs. But in the Jini world, you don't want to have to know
where the code came from. That should be an implementation detail.

Say you are a service, and I have a proxy from you. I don't want to
have to know what URL you serve code from. One reason I can't do a
static grant is I generally don't know where your code comes from. I
don't want to grant permissions to code from anywhere because that
would be granting to untrusted code. And even if I know where your
code is now, you might change your mind later about whether that is
really the trusted code or not. What I really want to do is wait until
after I have decided I trust the proxy before I grant it any permission.
If I grant it permissions before I decide I trust it, then it may have
already abused those permissions behind my back and already done
damage.

From the time I unmarshal that object, if I have already granted it
permissions, it can already exercise those permissions while it is being
unmarshalled. So I want to make sure that I don't grant it any
permissions until after I decide I trust it. That is where the dynamic
granting comes into play. I don't want to characterize these
permissions in a static security policy. At runtime I get a proxy from
somewhere. I decide I trust it. And then I want to grant it permissions.