Hi Peter, > Nice to have you back
I'm always reading the list, rarely have time to do anything about it though. I don't suppose my situation is unique... > got an example of your proxy wrapper? Sadly not, it was written for my previous employer and therefore the code is protected as part of their IP. I don't see any reason why I can re-invent it though. Thanks for the explanation about what you're up to. My concerns about introducing a dependency/coupling on OSGi through this approach still stands though. I think it should either be named as an OSGi End Point (or whatever it may be) to avoid suprises, or you should abstract away the OSGi classes so people can provide their own implementations of this security behaviour. I'd be in favour of the abstraction way, since it would match the other pluggable components that Jini/River users can choose. I'm sure you've already thought of that, though. I know it seems like I'm choosing the curtains and wallpaper before you've built the house, but I think this is worth bearing in mind. Cheers, Tom On Thu, Feb 4, 2010 at 11:00 AM, Peter Firmstone <[email protected]> wrote: > 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? >>> >>> >>> >>> >> >> >> > >
