Hi Tom,
Nice to have you back, got an example of your proxy wrapper?
The Endpoint, would be based on an SSLEndpoint, it is for traversing
NAT's for Services that we'd like to make public but can't due to the
private IP address being invisible.
Some NAT's change their ports dynamically, it appears the sockets can
deal with the dynamic ports (although I haven't confirmed this) however,
it is very likely that the connection will be subject to breakage and
will have to be renegotiated again by a public mediator service.
Unfortunately due to Jini's security model, you can dynamically grant a
permission, but once, I implemented a RevokeablePermission class which
dynamically removes a Permission after has been granted, but I found the
OSGi Conditions model more elegant. Conditions allow you to have a
number of dynamic tests in place that confirm it is safe to grant a
Permission. In this case, after we have been disconnected there is no
way of knowing we have the same service apart from questioning the proxy
for it's identity, however we cannot trust the proxy anymore and we need
to repeat the proxy trust process. If the connection cannot be re
started within a short time frame, I'd re-throw the exception. That
would enable you to handle the loss of service in various other ways.
The problem for my Revokeable permission is that it revokes permission
from the entire PermissionDomain, not very fine grained at all, like
using a Sledge Hammer to swat a fly! If there are other services in the
same ClassLoader (for memory efficiency reasons) we need to distinguish
them by their Principal, so only the Services that experienced a
temporary disconnection is denied Permissions until it is re verified.
Once the connection was re established, a permission exception would be
thrown until the proxy trust is verified again.
Cheers,
Peter.
Tom Hobbs wrote:
Not being a guru of any description I can't help you with the specific OSGi
questions, but your post makes me assume a few things about your intentions.
Can you clarify, if only for my benefit, please?
Or does the JERI Endpoint catch the exception and try to find it itself?
The Endpoint finds the service based on identity, it has moved, we must re
verify our Trust because the Conditions have changed.
This suggests to me, and I've been wrong before so it's no surprise if I am
again, that you're starting to couple the OSGi security mechanisms into this
custom JERI Endpoint. If that assumption is correct, can you start
referring to it as an OSGi Endpoint (which should be able to swap between
JERI and JRMP, maybe)? Or a Secure JERI Endpoint that is configured to use
the OSGi security mechanism although another, as yet unspecified one, could
be swapped in instead (which means hiding the OSGi stuff behind a common
interface).
I've been involved with wrapping proxies to provide auto-discovery behaviour
before and it works very well. The business code only ever gets
RemoteExceptions when a service really can't be found which means a lot less
"wait-and-retry" boilerplate code has to be written.
Barring someone categorically declaring that the EndPoint is the Wrong Place
to do it because the Jini spec says "xyz", it's probably just a matter of
taste which approach is the 'right' one. Personally speaking, it doesn't
"seem" like it's the EndPoint's job to go away and find a replacement for a
broken/missing service, as far as I'm aware no other EndPoint does that
(again, I'm happy to be corrected). If you do this, do you now call it a
Service Refinding Secure JERI EndPoint? Which makes it sound like the one
area of code is now doing a lot of different jobs...
Sorry I can't help with the OSGi specific questions.
Tom
On Thu, Feb 4, 2010 at 6:23 AM, Peter Firmstone <[email protected]> wrote:
I want to load Marshalled Objects from different locations with identical
bytecode into the same ClassLoader, I want to do this using codebase
services and OSGi, which gives me another level of indirection and a richer
security model with Condition's
PermissionDomain has a 1:1 relationship with ClassLoader
Trust Verifiication.
Identity and Authentication.
What distinguishes different services (from different remote locations and
domains) utilising the same ClassLoader, PermissionDomain and bytecode?
Principals.
I wonder if Conditions can apply to Principals? Such that when a proxy has
lost connection with its service node, the Condition denies a Principal
relating to that proxy any Permission, until the Service can be asked to
verify it's proxy again? I was thinking that the proxy itself doesn't
attempt to find its lost service, instead that would be done by a new JERI
Endpoint implementation, to do that the Endpoint needs to know the Service's
Identity.
Any OSGi guru's out there?
So we have Permissions being granted at different levels and we have
Conditions that make those Permissions Dynamic:
Principal - Can I trust the service? Can I grant it a Permission? What
are the current Conditions?
PermissionDomain & ClassLoader - relates to the Code Signer (which may be
different to the Service Principal). Do I trust the bytecode? If I do, the
bundle tells me the Permissions required to execute that bytecode.
Lets imagine for a moment, were happily using a Service, and suddenly it
throws a RemoteException, after some a wait period, we retry, the service
hasn't returned, so do we ask the JERI Endpoint to find the service? Or
does the JERI Endpoint catch the exception and try to find it itself? The
Endpoint finds the service based on identity, it has moved, we must re
verify our Trust because the Conditions have changed. So now we must catch
a Permission denied exception, and go through the re-verification process.
Does Bob Scheifler still watch the list? Anyone know where I can find Bob?
