Previous | Table of Contents | Next |
Certain policies that pertain to services like security (e.g., QOP, Mechanism, invocation credentials, etc.) are associated
by default with the process/capsule(RMODP)/ORB instance (hereinafter referred to as “capsule?) when the application is instantiated
together with the capsule. By default these policies are applicable whenever an invocation of an operation is attempted by
any code executing in the said capsule. The Security service provides operations for modulating these policies on a per-execution
thread basis using operations in the Current interface. Certain of these policies (e.g., invocation credentials, qop, mechanism,
etc.) which pertain to the invocation of an operation through a specific object reference can be further modulated at the
client end, using the set_policy_overrides operation of the Object reference.
For a description of this operation see Section 4.3.9, “Overriding Associated Policies
on an Object Reference? on page 4-20. It associates a specified set of policies with a
newly created object reference that it returns.
The association of these overridden policies with the object reference is a purely local phenomenon. These associations are
never passed on in any IOR or any other marshaled form of the object reference. the associations last until the object reference
in the capsule is destroyed or the capsule in which it exists is destroyed.
The policies thus overridden in this new object reference and all subsequent duplicates of this new object reference apply
to all invocations that are done through these object references. The overridden policies apply even when the default policy
associated with Current is changed. It is always possible that the effective policy on an object reference at any given time
will fail to be successfully applied, in which case the invocation attempt using that object reference will fail and return
a CORBA::NO_PERMISSION exception. Only certain policies that pertain to the invocation of an operation at the client end can
be overridden using this operation. These are listed in the Security specification. Attempts to override any other policy
will result in the raising of the CORBA::NO_PERMISSION exception.
In general the policy of a specific type that will be used in an invocation through a specific object reference using a specific
thread of execution is determined first by determining if that policy type has been overridden in that object reference. if
so then the overridden policy is used. if not then if the policy has been set in the thread of execution then that policy
is used. If not then the policy associated with the capsule is used. For policies that matter, the ORB ensures that there
is a default policy object of each type that matters associated with each capsule (ORB instance). Hence, in a correctly implemented
ORB there is no case when a required type policy is not available to use with an operation invocation.