The marker interface used to identify constraints for method invocations.
Implemented by constraints that are expressed in terms of relative time, to support conversion to absolute time constraints.
Defines an interface to proxies for setting constraints to control remote method calls.
Represents a constraint on authentication of the client to the server.
Represents a constraint on the client, such that if the client authenticates itself, then it may only authenticate itself as one or more of the specified principals.
Represents a constraint on the client, such that if the client authenticates itself, then it may only authenticate itself as principals that are instances of one or more of the specified classes.
Represents a constraint on the client, such that if the client authenticates itself, then it must authenticate itself as at least all of the specified principals.
Represents a constraint on the client, such that if the client authenticates itself, then it must authenticate itself such that, for each specified class, at least one authenticated principal is an instance of that class.
Represents a constraint on the confidentiality of message contents.
Represents a constraint on the absolute time by which a network connection must be established.
Represents a constraint on the maximum amount of time to wait for a network connection to be established.
Combines two or more constraint alternatives into a single overall constraint.
Represents a constraint on delegation from the client to the server.
Represents a constraint on delegation, such that if delegation is permitted, it be permitted only for a range of absolute times.
Represents a constraint on delegation, such that if delegation is permitted, it be permitted only for a range of time measured relative to the start of the remote call.
Represents a constraint on the integrity of message contents, covering not only data transmitted in band as part of the remote call itself, but also out-of-band downloaded code.
An immutable aggregation of constraints into a set of requirements and a set of preferences.
Represents a constraint on authentication of the server to the client.
Represents a constraint on the server, such that if the server authenticates itself, then it must authenticate itself as at least all of the specified principals.
Represents an invariant constraint on
RemoteMethodControlinterface implemented by the proxy. At each remote call through a proxy, the proxy implementation is responsible for using communication mechanisms that satisfy the client's constraints. If the constraints cannot be satisfied, the proxy throws a
InvocationConstraintinterface. The constraint mechanism is designed to be extensible; the constraint classes defined in this package should be adequate for many applications, but additional constraint classes, either generic in nature or specific to a particular mechanism or service, can be defined as necessary. By design, the constraints defined in this package express what control is desired, not how that control should be achieved; the constraints are not tied to specific algorithms, mechanisms, or protocols. Although most of the constraints defined in this package are related to trust mechanisms, it is intended and expected that a wide variety of constraints will be defined, particularly in the area of quality of service.
The basic trust-related constraints are very simple:
net.jini.core.constraint.AtomicValidation- to make sure that untrusted messages and objects (the data) sent over the network that could potentially be tampered with by third parties cannot do harm. Without this constraint, many of the following constraints are subject to reference stealing attacks during serialization.
Integrity- to make sure that the messages and objects (not just data, but also downloaded code) sent over the network are not tampered with by third parties
ServerAuthentication- to prove to the client that the server is executing on behalf of some subject, so that the call can be terminated if the subject is not trusted by the client. The flip side of this is anonymity: to allow a server to remain anonymous when it wants to be.
ClientAuthentication- to prove to the server that the client is executing on behalf of some subject, so that the server can perform only those tasks for which the subject is authorized. The flip side of this is anonymity: to allow a client to remain anonymous when it wants to be.
Delegation- to allow the server to authenticate as the client in remote calls made and received by the server, to allow the server to act on a client's behalf when dealing with third parties, in cases where the identity of the client (not the server) is what matters to those parties.
There are also constraints to control which principals of a client or server subject must be authenticated, and which principals of a client are permitted to be authenticated:
ClientMinPrincipal- to require a client to authenticate as at least some specific principals
ClientMaxPrincipal- to require a client to authenticate as at most some specific principals
ClientMinPrincipalType- to require a client to authenticate as at least some specific types of principals
ClientMaxPrincipalType- to require a client to authenticate as at most some specific types of principals
ServerMinPrincipal- to require a server to authenticate as at least some specific principals
(There is no
ServerMaxPrincipal constraint; a client
should not need to impose such a maximum, and a server can impose a maximum
by limiting the contents of the subject it uses for network authentication.)
There are also constraints to control the time during which a server is permitted to exercise delegation:
DelegationAbsoluteTime- to specify a range of absolute times
DelegationRelativeTime- to specify a range of times relative to the start of the remote call
ConnectionRelativeTime- to control the maximum amount of time to wait for a network connection to be established
ConnectionAbsoluteTime- to control the maximum absolute time by which a network connection must be established
Confidentiality- to make sure that the data sent over the network cannot be interpreted by third parties
There are no explicit don't care constraints; a don't care condition is expressed by the absence of constraints.
Constraints can be combined using
express alternatives, such that at least one of the individual constraints
must be satisfied (but not all have to be satisfied) for the aggregate
constraint to be satisfied.
aggregates constraints into a set of requirements and a set of preferences. A
requirement is a mandatory constraint that must be satisfied. A preference is
a desired constraint, to be satisfied if possible, but it will not be
satisfied if it conflicts with a requirement. If two preferences conflict,
it is arbitrary as to which one will be satisfied. If a constraint is not
understood, due to lack of knowledge of the type of the constraint or the
contents of the constraint, then the constraint cannot be satisfied.
defines a mapping from
InvocationConstraints, allowing different constraints to be
specified for different methods. For example, a client might require client
authentication for write operations but not for read operations, or a client
might care about the confidentiality of some remote calls but not others.
Although the emphasis in this discussion has been on how clients use constraints, constraints typically are also used by servers to specify their minimum requirements for remote calls. When a remote object is exported, the server's constraints normally are copied from the exporter into the returned proxy, so that the proxy knows the minimum constraints required to communicate with the server. Note that constraints are not used to specify server-side authorization (access control) policy.
RemoteMethodControlinterface to allow clients to impose constraints on remote calls. If a proxy implements this interface, then the semantics of this interface apply to all calls through all remote methods defined by the proxy; there is no mechanism to exempt remote methods or remote interfaces from these semantics.
Constraints for a remote call come from two sources:
MethodConstraintsinstance, so the client can specify different constraints for each remote method. Client constraints placed directly on a proxy apply to all remote calls made through that particular proxy by any thread. The server constraints are controlled by the proxy implementation; they are not exposed to the client, and might vary in ways unknown to the client (for example, vary by method or over time). The client should set the constraints it wants rather than assuming that the server imposes particular constraints.
A remote call will be performed only if the combined requirements (from both
sources) can be satisfied. If the requirements cannot be satisfied, the proxy
ConnectIOException, typically containing (but not
required to contain) a nested
UnsupportedConstraintException. In addition
to the requirements, both client and server preferences will be satisfied, to
the extent possible. Note that it is possible to specify conflicting
constraints, meaning they cannot be simultaneously satisfied. Preferences that
conflict with requirements are ignored, and if preferences conflict with each
other it is arbitrary as to which (if any) are satisfied, but if there are
conflicting requirements the remote call will not be made.
Copyright 2007-2013, multiple authors.
Licensed under the Apache License, Version 2.0, see the NOTICE file for attributions.