It may often be necessary for a
server object to provide different privilege levels
to different clients. For instance if you have a file server the file server may
have different access privileges to different classes
of users. And in order to facilitate
that kind of a differential invocation of
objects, the security model that Spring provides is
via what is called a front object, so this is the underlying object. And an
underlying object may have a front object that
is completely outside of the Spring semantics for
object invocation. The connection between the front object
and the underlying object is entirely within the
purview of the implementer of the service. In
other words, this connection is not through the
door mechanism that I told you about that Spring
system provides you. So, all that the client domain is
going to be able to do is access the front
object. And the front object will register the door for
accessing it with the nucleus, so that the client
can go through this door to this front object, and
the front object is the one that is going to
then check the access control list, ACL, in order to
see what kind of privileges this client domain
has in order to make an invocation on
the underlying object. And it is possible to
have multiple front objects to the underlying objects with
distinct doors registered with the Nucleus for different
implementation of control policies that you want for
a particular service. So, in other words, the
policies that you want for accessing the services available
in an underlying object can be implemented in
this front object or different instances of this front
object depending on how many different control policies
you want. So when a client invocation comes in
through this door to the front object, the
ACL, the access control list is checked before allowing
this invocation to actually go through to the
underlying object. As I mentioned earlier if this client
domain has access to an invocation entry point in
a server, that is it has access to a
door, the client domain can pass this around because
of the software capability. And the software capability can
be passed around by the client domain to other
domains in order to use that same capability to
access the same object. But in so doing the
client domain can decide whether it wants to give the
same privilege for accessing this object or lesser
privilege than what it has. Those are the things
that can be implemented as policies through this front
object. For example, let's say that the user wants
to print a file foo. The user, of course, has full access to the file system for
this particular object, that is the file that the
user has created. This is a reference to the
object foo and user has full access to that.
But it wants to print the file. But it
doesn't want to give privilege to the printer object
any more privilege than it needs to have to print
this. In particular, if I want to print a file, then all I need to do is give a
one-time privilege to the printer object in order to
print that file. So what I'm going to do is
I'm going to take this capability that I've
got for this file foo, reduce the privilege level
and say that you've got a reference to the
same object, but you have a one time reference.
Now the printer object can access the file system
and present its capability, and the front object, which
is associated with the file system, will verify that
yes, the one-time ticket that this guy has is
not expended yet, and therefore it is allowed to
access this file so that it can do its
job of printing. But if it tries to present
the same handle again, it'll be rejected by the
front object associated with the file system because this
is a one-time reference. The capability that is being
provided by the user the printer is a one-time
capability. So we've seen how object invocation can happen efficiently
through the door mechanism and the thread hand-off
mechanism that I mentioned within a single node,
and it can happen efficiently across the network
through the proxies, and it can also happen
securely by the fact that you can associate
policies in front objects that govern access to
the objects. So these are all the mechanisms
that are provided in the Spring kernel and
this is where the innovation happens. Or in another words, the
external interface, even though it is a Unix operating system, under
the cover the Spring system does all of these innovation in
terms of how to structure the operating system itself using object technology.