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?
