Jeri/SSL export question

[Esmond Pitt]

Do I have these exporters and ILFactories the right way round?

Exporter mainExporter = new BasicJeriExporter(ep, new
ProxyTrustILFactory(serverConstraints, null));
Exporter bootExporter = new BasicJeriExporter(ep, new
BasicILFactory(serverConstraints, null));
this.exporter = new ProxyTrustExporter(mainExporter, bootExporter);

It seems to work, and reversing the ILFactories doesn't, but actually I
don't really understand what's going on here.

TIA

EJP

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com

[Peter Jones]

Post by Esmond Pitt
Do I have these exporters and ILFactories the right way round?
Exporter mainExporter = new BasicJeriExporter(ep, new
ProxyTrustILFactory(serverConstraints, null));
Exporter bootExporter = new BasicJeriExporter(ep, new
BasicILFactory(serverConstraints, null));
this.exporter = new ProxyTrustExporter(mainExporter, bootExporter);
It seems to work, and reversing the ILFactories doesn't, but actually I
don't really understand what's going on here.

You generally don't use both ProxyTrustILFactory and
ProxyTrustExporter together.

You can use ProxyTrustILFactory if there is one proxy that can serve
both for application remote invocation (either directly or as the
inner proxy within a "smart proxy") and as the bootstrap proxy for
trust verification (i.e. the proxy that can be trusted by a client's
local trust verifiers).

You use ProxyTrustExporter, which is a more general mechanism, if you
need to use a different proxy for bootstrapping trust verification
than you want to use for application-level remote invocations (like if
you want to use a custom Endpoint or invocation handler, which
wouldn't be locally trusted for bootstrap verification, for the
latter).

That being said, using ProxyTrustILFactory with mainExporter as above
shouldn't cause harm. The problem with reversing them, I suspect, is
that ProxyTrustILFactory will complain that the bootstrap remote
object internally supplied by ProxyTrustExporter does not implement
ServerProxyTrust-- rather, it implements ProxyTrust directly,
forwarding getProxyVerifier invocations to
ServerProxyTrust.getProxyVerifier of the main remote object.

-- Peter

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com

[Esmond Pitt]

Thanks Peter, getting there.

If I just use the BasicJeriExporter with the ProxyTrustILFactory for an SSL
endpoint, the server must implement ServerProxyTrust according to the
exceptions I get. But the getProxyVerifier() method never seems to be
called: what's going on here?

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com

[Peter Jones]

Post by Esmond Pitt
If I just use the BasicJeriExporter with the ProxyTrustILFactory for
an SSL endpoint, the server must implement ServerProxyTrust
according to the exceptions I get. But the getProxyVerifier() method
never seems to be called: what's going on here?

You're saying that its getProxyVerifier method isn't invoked even
after a client has passed its proxy to Security.verifyObjectTrust
(perhaps indirectly through a BasicProxyPreparer)? We probably need
to see more code in order to speculate what's going on.

Or was the proxy a "bootstrap stub" synthesized by the client, like
the subject of your previous thread? In that case, the proxy may well
be fully trusted by the client's local trust verifiers, in which case
the remote object's getProxyVerifier wouldn't get invoked. (The same
could be true if attempting to verify the proxy returned by the export
operation in same server JVM.)

-- Peter

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com

[Esmond Pitt]

Thanks Peter, I have in the server as discussed:

Exporter exporter = new BasicJeriExporter(ep, new
ProxyTrustILFactory(serverConstraints, permClass), dgc, keepAlive,
RemoteSubject.UUID);
Remote stub = exporter.export(this);

and in the client:

ProxyPreparer pp = new BasicProxyPreparer(true, clientConstraints, permissions);
RemoteSubject rs = (RemoteSubject)pp.prepareProxy(stub);
// execute calls on rs

where RemoteSubject is my remote interface. The server implements
ServerProxyTrust by returning a new BasicProxyTrustVerifier(stub). A
breakpoint on this line is never reached.

Again I have to say I'm still not 100% clear about all this, although the
fog is clearing. Basically I'm trying to use JERI/SSL in the securest manner
possible, and specifically with ServerProxyTrust.getProxyVerifier() being
executed, without using my own proxy stubs.

EJP

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com

[Peter Jones]

Post by Esmond Pitt
Exporter exporter = new BasicJeriExporter(ep, new
ProxyTrustILFactory(serverConstraints, permClass), dgc, keepAlive,
RemoteSubject.UUID);
Remote stub = exporter.export(this);
ProxyPreparer pp = new BasicProxyPreparer(true, clientConstraints, permissions);
RemoteSubject rs = (RemoteSubject)pp.prepareProxy(stub);
// execute calls on rs
where RemoteSubject is my remote interface. The server implements
ServerProxyTrust by returning a new BasicProxyTrustVerifier(stub). A
breakpoint on this line is never reached.

How does the clinet get the value for "stub"?

Post by Esmond Pitt
Again I have to say I'm still not 100% clear about all this,
although the fog is clearing. Basically I'm trying to use JERI/SSL
in the securest manner possible, and specifically with
ServerProxyTrust.getProxyVerifier() being executed, without using my
own proxy stubs.

I'm not sure what you mean by "without using my own proxy stubs".

Post by Esmond Pitt
Further to this, it seems that the server's getProxyVerifier() method isn't
being called because the stub passes one of the other verifiers first every
time through Security$Context.isTrustedObject(). The ProxyTrustVerifier is
configured as the 5th verifier, i.e. index [4], and i never gets beyond 2 in
that loop, throughout all the recursions.
This seems odd to me. Surely the stub should pass +all+ the verifiers, not
just one of them?

No, the stub (or any given object) only needs to be pass one verifier.
See the API doc for TrustVerifier.Context.isTrustedObject, and section
3.2.1 of the 2.x starter kit "overview" document[1]. The variety of
available verifiers serves to support verifying for different kinds of
objects or by using different mechanisms. Note that the trust
verifier context can be invoked recursively for contained objects,
thus enlisting other verifiers to help fully verify a containing
object-- and that typically occurs when verifying a JERI stub.

-- Peter

[1] Online here:
http://java.sun.com/developer/products/jini/arch2_0.html

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com

[Esmond Pitt]

Further to this, it seems that the server's getProxyVerifier() method isn't
being called because the stub passes one of the other verifiers first every
time through Security$Context.isTrustedObject(). The ProxyTrustVerifier is
configured as the 5th verifier, i.e. index [4], and i never gets beyond 2 in
that loop, throughout all the recursions.

This seems odd to me. Surely the stub should pass +all+ the verifiers, not
just one of them?

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com

[Esmond Pitt]

The client got the stub via a registry lookup.

There are no dynamic proxies in the system, only stubs generated by JERI.

So should I not be expecting the ServerProxyTrust method to be called, is
that what it comes down to?

TIA

EJP

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com

[Peter Jones]

Post by Esmond Pitt
The client got the stub via a registry lookup.

Does the stub have no codebase annotation? That would be another case
where BasicJeriTrustVerifier (along with verifiers for subcomponents
like SslTrustVerifier) should be able to verify an uncustomized JERI
stub without requiring ProxyTrustVerifier, because without a codebase
annotation the dynamic proxy class's loader should be a "relatively
local" loader trusted by BasicJeriTrustVerifier.

Post by Esmond Pitt
There are no dynamic proxies in the system, only stubs generated by JERI.

(A stub resulting from exporting with JERI generally has a dynamic
proxy as its outermost object, so I'm not sure you meant to say that.)

Post by Esmond Pitt
So should I not be expecting the ServerProxyTrust method to be
called, is that what it comes down to?

Not if the stub can be verified without using ProxyTrustVerifier, like
as described above, because BasicJeriTrustVerifier is sufficient.

Passing this verification means that the stub can be trusted to
implement constraints on remote invocations, like Integrity.YES,
ServerAuthentication.YES, and ServerMinPrincipal, so that the client
can be sure that invocations on the stub only communicate with the
specified principal, regardless of from where or whom the stub was
initially obtained.

-- Peter

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com

[Esmond Pitt]

Peter

Post by Peter Jones
Does the stub have no codebase annotation?

Correct. No codebase. Just local class loading.

Post by Peter Jones

Post by Esmond Pitt
There are no dynamic proxies in the system, only stubs generated by JERI.

(A stub resulting from exporting with JERI generally has a dynamic
proxy as its outermost object, so I'm not sure you meant to say that.)

What I'm trying to say here is that I have no smart proxies of my own, only
what JERI is giving me.

Thanks all for the enlightenment.

EJP

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com

[Peter Jones]

Post by Esmond Pitt

Post by Peter Jones
Does the stub have no codebase annotation?

Correct. No codebase. Just local class loading.

OK, that explains it then.

ProxyTrustVerifier, and its associated mechanisms like the
(Server)ProxyTrust.getProxyVerifier methods, are (as described in the
net.jini.security.proxytrust API docs) intended for trust verification
in the face of RMI-style dynamic class loading for service proxies--
if you're not doing that, you don't need PTV.

-- Peter

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to ***@java.sun.com