Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more

[Mark Brouwer <ma...@cheiron.org>]

Part I
------

I was looking for a way to control the principal a lookup server should
authenticate itself in the unicast discovery protocol in case the
subject contains multiple principals. I couldn't find a way as it turns
out the Kerberos and SSL unicast discovery provider implementation (of
which there can only be one) create an SslServerEndpoint which doesn't
let you control the principals, (e.g. com.sun.jini.discovery.ssl.Server
line 107).

As the server side of the discovery providers is not something that I
necessarily need to have available as part of the Platform (it is lookup
server functionality in the end) I could have decided to hack the code
to allow for configuration of the principals as part of my lookup server
implementation but in that case I will run into the outstanding JDC bugs
4893510 and 4893513.

Any ideas how to work around this or the plans with regard to 4893510
and 4893513.


Part II
-------

Also something I'm wondering over these days is why the public API in
com.sun.jini.discovery never was proposed in the net.jini.discovery
namespace.

As an example. People writing JSC Services often end up using utilities
such as ServiceDiscoveryManager because they use libraries that use SDM
or their code must also run outside Seven (which has its ServiceFinder
equivalent). Using SDM also puts the burden on service implementors to
drag in all the implementation details, i.e. com.sun.jini.discovery API
and the various service provider implementations. Assuming they did this
correctly (which from experience I know is not always the case, for
service provider implementation won't be selected by an ordinary
dependency check) they end up with their own service provider
implementations that they have to configure themselves which I can say
is not trivial when you take security into account.

In case the Discovery related API and service provider selection would
have been a 'standardized' public API and mechanism, people can build on
top of that utilities. The configuration of Platform provided service
providers can then be left to the Platform implementors such as Seven
while they can still add their own service providers for cases not
supported by the Platform.

Any comments?

BTW in seven I implicitly used this strategy as result of bug 4893510
and 4893513 and it turned out to be an advantage too for those utilizing
SDM as part of a JSC Service, but as is it is rather brittle because you
never know whether people modify the API of classes in the
com.sun.jini.discovery because these are not 'standard'.
-- 
Mark

Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> My motivation is to include such an API as part of a Platform for the
> motivation given below (from my initial posting):

Sorry for being unclear, I understand that, the discussion I was
referring to was around the value of keeping everything in the
"platform" in the net.jini namespace.

- Bob

Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Mark Brouwer wrote:
>>> That work was done very late in the release cycle, and it had
>>> little design review even internally at the time (IIRC).
>>
>> Am I correct that from the above I may conclude (given
>> it enough review and field testing) it would be a candidate as far as
>> you are concerned?
> 
> Sure, although if that means redoing into the net.jini namespace,
> it will be worthwhile to have a discussion on the real value of doing so.

My motivation is to include such an API as part of a Platform for the
motivation given below (from my initial posting):

"In case the Discovery related API and service provider selection would
have been a 'standardized' public API and mechanism, people can build on
top of that utilities. The configuration of Platform provided service
providers can then be left to the Platform implementors such as Seven
while they can still add their own service providers for cases not
supported by the Platform."

E.g. LookupDiscovery and LookupLocator implementations can be built on
top of such an API in a portable way, no need to drag all the com.sun or
future org.apache.river implementation code as is currently the case.
-- 
Mark

Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
>> That work was done very late in the release cycle, and it had
>> little design review even internally at the time (IIRC).
> 
> Am I correct that from the above I may conclude (given
> it enough review and field testing) it would be a candidate as far as
> you are concerned?

Sure, although if that means redoing into the net.jini namespace,
it will be worthwhile to have a discussion on the real value of doing so.

- Bob

Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Mark Brouwer wrote:
>> Also something I'm wondering over these days is why the public API in
>> com.sun.jini.discovery never was proposed in the net.jini.discovery
>> namespace.
> 
> That work was done very late in the release cycle, and it had
> little design review even internally at the time (IIRC).

Ok, thanks. Am I correct that from the above I may conclude (given
it enough review and field testing) it would be a candidate as far as
you are concerned? Especially as the discovery and join protocols were
once defined as part of the Jini technology infrastructure that
represented the minimal Jini technology core (Jini Architecture
Specification).

Just some info but without going into the details. During my work for
"Jini across the Firewall" I felt the need for
Discovery.doUnicastDiscovery() and Discovery.handleUnicastDiscovery()
methods that take an Input/OutputStream instead of a Socket, so that is
also something to look into.

And as result of https://issues.apache.org/jira/browse/RIVER-16 I added
some API in com.sun.jini.discovery that allows me to write 'plugins'
that enabled me to unify trust related questions for both unicast and
multicast discovery.
-- 
Mark

Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> Also something I'm wondering over these days is why the public API in
> com.sun.jini.discovery never was proposed in the net.jini.discovery
> namespace.

That work was done very late in the release cycle, and it had
little design review even internally at the time (IIRC).

- Bob