Peter Firmstone wrote:
Peter Jones wrote:
On Jun 19, 2011, at 5:37 AM, Peter Firmstone wrote:
The easiest way to set DGC constraints would be via configuration.
Perhaps the reason this hasn't been implemented previously is, the
constraints would apply to all services that use DGC, so if you've
set Authentication and Integrity as minimal constraints, then this
would apply to all services.
As mentioned offline, I'm not sure how much of this I can page into
my consciousness at the moment.
Configuring the server-side constraints for DGC could probably be
supported with additional parameters to the export process (and thus
set via configuration). The bigger issue, I think, is what client
constraints to apply, and what client subject to use, when JERI's
client-side DGC system (defined within BasicObjectEndpoint) makes
"dirty" and "clean" calls on behalf of the application. In the
traditional RMI DGC model, those calls happen implicitly as remote
references appear and disappear from a JVM. But in the JERI security
model, the client application controls the security behavior of
remote calls by explicitly (with respect to the standard JERI layers)
specifying constraints and controlling the current subject.
So when the system wants to make a "dirty" or "clean" call for a
given remote reference (forget batching for the moment), what
constraints to apply, or what subject to use? There didn't seem to
be an answer, without requiring the client application to interact
with the DGC system more explicitly, which would be a significant
change from the RMI DGC model-- and, I think, not something that
seemed worth investing effort on at the time, especially given that
Jini services didn't seem to make use of RMI's DGC functionality in
practice anyway (instead they used higher-level leasing mechanisms to
detect client "failure", and most interest was around just being
disable DGC for Jini services).
The higher level mechanisms I've seen duplicate a lot of
functionality, eg use weak reference notifications, leases etc, this
is what DGC uses, so it would appear to save some work.
Restoring the Subject after privileged execution blocks can be
expensive too.
I guess the main concern is, the call hasn't been tampered with and
originates from the correct client, eg the clientID hasn't been forged
or altered.
SSLEndpoint can provide integrity but it requires at least server
authentication, but it's the client that needs authenticating.
I wonder if ImplRef can be used to store the Subject at the server,
different services might use different authenticating subjects.
The client would need an object table that tracked the authenticating
subject used for each BasicObjectEndpoint.
The problem with the above statement is it would cause problems when the
DGC client wanted to update the lease for all BasicObjectEndpoint's
Uuid's in a single dirty call for a specific Endpoint.
A possible solution:
A DGC client would need to group BasicObjectEnpoints authenticated with
identical subjects and submit each grouping separately in repeated dirty
calls. This would result in the Lease being updated at the server each
time, but with Targets for each Uuid (representing BasicObjectEndpoints)
sequence numbers must not be incremented for each subsequent call in the
batch, Targets maintain their own record of sequence numbers for each
client and would not be updated until a call is made with the particular
targets Uuid included in the dirty call's Uuid[] ids parameter.
This means that clean calls could be batched in the same way with
identical sequence numbers for an Endpoint with multiple
BasicObjectEndpoints with uncommon Subjects and Targets would be removed
from the lease for each clean call, until no targets remain in the lease.
Because the sequence number doesn't need to be incremented for these
single Endpoint uncommon Subject groupings, it preserves the sequencing
required to identify the order of clean and dirty calls for each Endpoint.
Any dirty calls that fail with SecurityException cannot be retried and
it wouldn't be safe to unmarshall the proxy, or if it did, garbage
collection would be disabled. The DgcServer would require a minimal set
of constraints or a ClientMinPrincipal consistent among all the services
that server provides to prevent the SecurityException occurring.
If the client of an arbitrary service with DGC enabled, lets the
reference to the proxy escape locally, then even though another subject
might be unauthorised to interact with that service due to constraints,
the act of holding a local reference to the arbitary service's proxy
will keep DGC updating the lease using the credentials of the a recorded
Subject.
This doesn't seem to be a big security issue however, it cannot be used
for denial of service, by holding onto some resources without causing
much load.
So each BasicObjectEndpoint would need to keep a Set of weakly
referenced Subjects, that recorded the Subject when a newCall succeeds,
to be used by AbstractDgcClient to find a common Subject among all
BasicObjectEndpoints for a specific Endpoint, in most cases it is likely
only one call would need to be sent for a single common Subject, but on
occasion multiple calls for different Subjects for an Endpoint would
need to be sent. The weakly referenced Subject means the
BasicObjectEndpoint doesn't prevent local GC of the Subject, in case it
logs out and another Subject is still using the BasicObjectEndpoint.
AbstractDgcClient would need some modifications so it doesn't increment
the sequence number for additional calls required for an Endpoint with
uncommon subjects in their BasicObjectEndpoints .
It is possible that a Target might not be removed by a clean call from a
lease in the DgcServer, if the clean call cannot authenticate (eg the
Subject has logged off and Subject has been locally garbage collected
while a strong reference is still held by the client to the
BasicObjectEndpoint) if that lease continues to be updated for other
targets at the client (a target represents a remote object) where the
lease for a particular client has a collection of targets, garbage
collection of that target will be delayed until the lease is allowed to
expire by the client. This seems to be a reasonable assumption.
It also doesn't require any changes in the server's DGC logic.
See any holes?
Cheers,
Peter.
