|
»
»
Jeri/SSL export question
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
Jeri/SSL export question
by Esmond Pitt FACS
::
Rate this Message:
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 listserv@... |
|
|
Re: Jeri/SSL export question
by Peter Jones - JavaSoft East
::
Rate this Message:
On Wed, Mar 18, 2009 at 07:04:19PM -0600, Esmond Pitt wrote:
> 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 listserv@... |
|
|
|
|
|
Re: Jeri/SSL export question
by Peter Jones - JavaSoft East
::
Rate this Message:
On Wed, Mar 25, 2009 at 05:38:26PM -0600, Esmond Pitt wrote:
> 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 listserv@... |
|
|
|
|
|
|
|
|
Re: Jeri/SSL export question
by Peter Jones - JavaSoft East
::
Rate this Message:
On Sun, Mar 29, 2009 at 05:27:09PM -0600, Esmond Pitt wrote:
> 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. How does the clinet get the value for "stub"? > 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". > 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 listserv@... |
|
|
|
|
|
Re: Jeri/SSL export question
by Peter Jones - JavaSoft East
::
Rate this Message:
On Mon, Mar 30, 2009 at 04:47:34PM -0600, Esmond Pitt wrote:
> 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. > 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.) > 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 listserv@... |
|
|
|
|
|
Re: Jeri/SSL export question
by Peter Jones - JavaSoft East
::
Rate this Message:
On Tue, Mar 31, 2009 at 03:54:02PM -0600, Esmond Pitt wrote:
>> 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 listserv@... |
| Free embeddable forum powered by Nabble | Forum Help |
