This part of security is enforced in the ORB, for example, through the "client access control interceptor" (Figure 15-53).
My question is: Can't the client circumvent the restrictions? Assume we use C++ for the application and the stubs objects. Now, does the ORB run in a different address space than the application
(incl. stubs)? Or is the client part of the ORB linked to the application at compile time (and thus running in the same address space)? If the ORB were in the same address space, then the client could just modify the ORB code to circumvent the policies that the administrator has imposed. Even if the ORB were running in a different address space, the client could still write a piece of software which behaves like the ORB, but leaves out the routines where administrative restrictions are enforced. The client could then his "custom ORB implementation" rather than the "real" ORB for communication, hereby circumventing administrative security policies.
In my Kerberos 5 based implementation I use GSS-API to get a ticket from outside the CORBA system. Then I use GSS-API to establish a security context between client and server. This is done at a very low level during the bind, before any IIOP messages are sent. If the server can't authenticate the client the connection is dropped. All IIOP messages are encrypted/decrypted using GSS function.
In theory such a system is quite bullet proof. In the real life an attacher might be able to exploit a buffer overrun on the server ORB and execute arbitrary code. There are some other possible attacks, too.