A Conversation with Bob Scheifler, Part VI

---

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 Part V, Scheifler describes the dynamic granting of permissions to proxies. In this sixth and final installment of the interview, Scheifler discusses Jini Extensible Remote Invocation.

Bill Venners: Can you give an overview of JERI?

Bob Scheifler: JERI is Jini Extensible Remote Invocation. JERI is a new implementation of the RMI programming model. So it is on a par with RMI's native JRMP protocol. It's also on a par with RMI/IIOP in the sense that all of these are implementations of the RMI programming model. They use different protocols underneath. They have different protocol stacks. They expose things to different degrees. But they all implement RMI semantics. One of the things we have always said about Jini is it is not about protocols. It is about interfaces. All of the services we ship to date use JRMP. That's an artifact because JRMP was the most convenient protocol to get the object semantics we wanted.

We always said JRMP is not necessarily the only protocol. JERI is now another example. It's a new implementation of RMI. It has the same kind of RMI semantics as JRMP, though not the same protocol stack. We'd like to be able to implement services with JERI as well. Clients still shouldn't care whether you use JERI, JRMP, or RMI/IIOP. As long as the protocol you choose meets the semantics of the interface you specify, that should be good enough.

Exposing the RMI Protocol Stack Layers

The purpose of JERI is to expose more of the underlying protocol stack layers than are currently exposed in J2SE or JRMP. JRMP has a notion of object references, for example, but it is not exposed in public Java classes. They are internal com.sun classes you are not supposed to use. There's a description in the RMI specification for protocol layering, but none of those services are public classes. So the idea behind JERI is to expose those layers explicitly within part of your public specification and allow customization.

In JERI, you can customize the different layers by plugging in different pieces or subclassing different pieces in order to tailor the behavior. JERI has three layers. There is a marshaling layer, where the marshaling of arguments and marshaling of return values and thrown exceptions takes place. There is an object invocation layer, which is a thin layer that identifies what remote object you try to make a call on. And then there is a transport layer that implements the messaging protocol of sending the remote call or the request to the server and getting the response back. The messaging layer doesn't know about these other layers above. It's a request/response messaging layer that has arbitrary bytes in it. It doesn't know what the bytes are. It is just responsible for transporting the bytes.

Customizing the Layers

JERI allows customization of two of those three layers. The object identification layer is thin enough right now that it's not worth customizing. One place where we focused on customization is the transport layer. Now that is similar to what you can already do in JRMP today. In JRMP, you can customize with an RMI socket factory. So JERI is similar to JRMP there, although the JERI transport layer has been abstracted more so that it is not socket specific. We upleveled the transport layer so that if you want to implement non-socket, non-TCP transports, you can do that.

At the marshaling layer, we allow customization so you can pass implicit parameters, pass extra data, code the method differently, code the arguments differently, put in access control checks, or whatever you need to do. Basically, that whole area is being exposed. Now the simplest way to approach it is that we provide JERI a standard invocation handler.

To step back, one of the design aspects of JERI is that if we don't have precompiled stubs anymore. There is no RMIC equivalent for JERI. We've switched over totally to using dynamic java.lang.reflect proxies. And a generated java.language.reflect proxy class is roughly equivalent to a stub class. A dynamically generated proxy implements all the interfaces and delegates to this object called an invocation handler. The invocation handler essentially has one method called invoke that takes the method object and all the arguments. In JERI, there is a standard unicast invocation handler that has all the standard marshaling semantics, but all the various stages are exposed as protected methods. If you want to subclass an invocation handler to either override or augment the semantics of each of those steps, you can do so via subclassing.

And, similarly, on the server side for JERI there is a dispatcher that is the analog to the invocation handler. The dispatcher gets the invocation and is responsible for unmarshaling and then making the upcall to the actual remote object. There is a standard dispatcher that has all of the steps exposed as protected methods. On the server side if you want to augment or replace semantics you can subclass the standard dispatcher. If you want to completely replace it, you can implement your invocation handler and your own dispatcher.

It is a little funny to describe JERI as a protocol because it has pieces of protocol, but you can plug in your own pieces. You can completely replace pieces of the protocol if you want. It is more of an architectural protocol stack, if you will, and it has default implementations to give you a complete stack. But one aspect of it is to make it highly customizable.

Secure JERI

Bill Venners: How does JERI help Jini security?

Bob Scheifler: There is JERI and then there is secure JERI. They are roughly siblings. If you look at it architecturally, there are some elements of secure JERI that are subinterfaces of JERI. But there are some that are siblings. It really depends on whether it makes sense to be a pure subclass, where we just have to add methods. In some cases, we had to add additional parameters, for example, to existing methods. You can't do that by subclassing. We had to effectively clone the interfaces and add additional parameters. So it is not like secure JERI is a subclass of JERI. In fact, you should think of it as a sibling. It has the same protocol stack and customizability, but it is infused with all of the security constraint stuff.

The intention is that secure JERI supports the constraint model that we have defined for remote calls. If you want a service that actually obeys this network security model, then you need something that is actually going to meet the requirements of these constraints. The easiest way to do that is to pick up a protocol stack that will do it for you. Secure JERI is an instance of a protocol stack that will do that for you.

In secure JERI almost all of the constraints are implemented in the transport layer. Almost all of the constraints are transport layer security mechanisms. The only thing that is implemented at a higher layer is code integrity because that happens at marshaling time when they create class loaders to download code. So the URL integrity check is done at the marshaling layer. All the others—authentication, confidentiality, integrity—are essentially transport-level notions.

Secure JERI is portable on all of those layers. It has a generic connection interface so it doesn't have to be socket or TCP based. It is designed so that different kinds of security mechanisms can be plugged in. For example, today there is a transport implementation that does the network security using SSL/TLS (Secure Sockets Layer / Transport Layer Security). It is implemented using the Java secure socket extension. We have another transport provider in the works that is Kerberos based. It uses the JGSS Java interface to the GSS (Generic Security Service) API. That gives you Kerberos-level security. The idea is you can plug in others to suit your needs.

Extensions to Activation

Bill Venners: What extensions have you made to activation?

Bob Scheifler: We have made very small extensions to activation. It is still on our issues list whether we should abandon the current activation API and design a new one. Currently, we are living within the current activation framework with its design. We wanted secure activation to work with secure JERI. It is not just for JRMP anymore. There are a few minor wrinkles, but so far they haven't been sufficiently annoying to throw the whole thing out and start over again. There is a lot of utility in keeping with the same API you already understand. There aren't any significant extensions in terms of the programming models.

We have done a new implementation of RMID we call Phoenix. RMID is JRMP specific and it is not customizable. What we have done with Phoenix is make it highly configurable so that you can configure it to use JRMP. You can configure it to use JERI. You can configure it to use secure JERI.

Configuration at Deployment Time

Bill Venners: You want the server to be configurable at runtime, not something the coder has to do, right?

Bob Scheifler: Yeah. Definitely one aspect of the network security model in a broader sense is that we want security choices to be made at deployment time without having to change your code. The last thing you want to do if you later decide you want confidentiality is to have to go edit Java code. What constraints you use and who the server should authenticate as should be choices you make at deployment time.

Complexity versus Usability

Bill Venners: What about complexity versus usability? If the security mechanism is too complex, people will make mistakes or just not use it. Are you concerned about the complexity of all this?

Bob Scheifler: Other people have expressed more concern about complexity than I have. Part of it has simply been that different people have different visibility to this stuff as it has evolved. In the early days we had a lot less high-level documentation than we do today to try and explain this.

The other way of looking at its complexity is as progressive refinement. There are a lot of detailed aspects here, but not everybody has to understand all of them. If I look at Java today, how many people understand how HotSpot works? Most people just say, "It is a virtual machine. I don't have to understand it." That doesn't mean there isn't a lot of complicated stuff there. But from a progressive refinement point of view, you don't have to refine down to that point. And the same thing is true here.

At a high level you say, "I understand these security constraints. I don't care how they are implemented." The next level down somebody might say, "I am a server. I have to implement security constraints, so I am going to use secure JERI. I don't have to understand how secure JERI works. I'll just use it." And the next level down guy says, "I have to implement a transport. So I have to understand a lot." But there aren't that many transport implementers. There are a lot of secure JERI users, and there are a lot more generic network security clients. You don't have to understand the whole ball of wax in order to use this stuff. You have to understand the high-level model. And you have to leave the various implementation tasks of that model to the right set of developers.

I think the perceived complexity comes more from when people look at overture and see 450 pages of documentation. They say, "My God, I have to understand all this!" And that is not the right way to think about it. The right way to think about is, "I need to go into the overviews and understand the models that are presented and the pieces of those models that I actually care about. At some point I might come back and have to care about the details of all of the rest." Just like you don't care about how the virtual machine is implemented, you don't need to understand how Jini security is implemented. You may be interested but you don't need to understand it to get your Java program done.

Getting Involved with Davis

Bill Venners: This development is occurring under the Davis project at jini.org. How do people find out more about it? How do they get involved?

Bob Scheifler: The way to get involved is to join the Davis project on jini.org. The Davis project is like any other project on jini.org. There is an area where you can go find what the Davis project is and download the overture release. And you can subscribe to the standard jini.org mailing lists.

Bill Venners: What is the overture release?

Bob Scheifler: The overture release is basically the specifications, APIs, and implementation for the security model, configuration, JERI, secure JERI. We have been putting out various overture releases as the security model has been refined. At some point, we will stop putting out overture releases and start putting out starter kits for early access releases. Today, overture is the new security infrastructure without any Jini stuff. The next step is to start using the new security infrastructure in Jini. Now that we have this security infrastructure, let's change lookup discovery and join manager, service discovery manager, Reggie, Norm, and Fiddler to actually use it. Once we start changing the Jini things to use this new security infrastructure, then we will start putting out starter kit early access releases that will have ongoing implementations of all this stuff. And so overture is really the infrastructure that we need to actually implement security configurability in Jini.

Resources

The Jini Community, the central site for signers of the Jini Sun Community Source Licence to interact:
http://www.jini.org

To get involved in the Davis project, in which Jini security is being defined, go to:
http://davis.jini.org/

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.