SEC. 9.1 CORBA 523
situation occurs for an object that is to be invoked. This approach leads to the general organization shown in Fig. 9-19.
Client application
Security service
Security service
Client ORB Local OS
Policy object
Policy object
Set of client-specific policy objects
Set of object-specific policy objects
Set of relevant ORB security services
Object implementation
Policy object
Policy object
Security service
Security service
Server ORB Local OS
Invocation
Network
Figure 9-19. The general organization for secure object invocation in CORBA.
When a client binds to an object in order to invoke that object, the client ORB determines which security services are needed at the client side to support secure invocations. The selection of services is determined by the security policies associated with the administrative domain in which the client is executing, but also by the specific policies of that client.
Security policies are specified by means of policy objects that are associated with the client. In practice, the domain in which a client is executing will make its security policies available to the ORB of that client by means of a specific set of policy objects. Default policies are automatically associated to clients. Example policy objects include those that specify the type of message protection that is required, and objects that have a list of trusted parties. Other examples and details can be found in( Blakley, 2000).
A similar structure is followed at the server side. Again, the administrative domain in which the invoked object is executing will require that a specific set of security services is used. Likewise, the invoked object will have its own set of associated policy objects in which object-specific information is stored.
Various approaches can be followed to implement security in CORBA. In particular, to make ORBs as general as possible, it is desirable to specify different security services by means of standard interfaces that hide the implementation of those services. Services that can be specified in this way are called replaceable in CORBA.
Replaceable security services are assumed to be implemented in combination with two different interceptors, as shown in Fig. 9-20. The access control interceptor is a request-level interceptor that checks the access rights associated with