| Previous | Table of Contents | Next |
The addition of value types has few impacts on the CORBA security model. In essence, the security implications in defining
and using value types are similar to those involved with the use of IDL structs. Instances of value types are mapped to local,
concrete programming language constructs. Except for providing the marshaling mechanisms, the ORB is not directly involved
with accessing value type implementations. This specification is mostly about two things: how value types manifest themselves
as concrete programming language constructs and how they are transmitted.
To see this consider how value types are actually used. The IDL definition of a value type in conjunction with a programming
language mapping is used to generate the concrete programming language definitions for that type.
Let us consider its life cycle. In order to use it, the programmer uses the mechanisms in the programming language to instantiate
an instance. This is instance is a local programming language construct. It is not “registered? with the ORB, object adapter,
etc. The programmer may manipulate this programming construct just like any other programming language construct. So far there
are no security implications. As long as no ORB-mediated invocations are made, the programmer may manipulate the construct.
Note, this includes making “local,? non ORB-mediated calls to any locally implemented operations. Any assignments to the construct
are the responsibility of the programmer and have no special security implications.
Things get interesting when the program attempts to pass one of these constructs through an orb-mediated invocation (i.e.,
calls a stub that uses it as a parameter type, or uses the DII). There are two cases to consider: 1) Value as Value and 2)
Value as Object Reference.
5.2.9.1 Value as Value
The formal type of the parameter is a value. This case is no different from using any other kind of a value (long, string,
struct) in a CORBA invocation, with respect to security. The value (data) is marshaled and delivered to the receiving context.
On the receiving context, the knowledge of the type is used (at least implicitly) to find the factory to create the correct
local programming language construct. The data is then unmarshaled to fill in the newly created construct. This is similar
to using other values (longs, strings, structs) except that the knowledge of the factory is not “built-in? to the ORB’s skeleton/DSI
engine.
5.2.9.2 Value as Object Reference
The formal type of the parameter is an interface type that is supported by a value. The program must have “registered? the
value with an object adapter and is really using the returned object reference (see for the specific rules.) Thus this case
“reduces? to a regular CORBA invocation, using a regular object reference. An IOR is passed to the receiving context. All
the “normal? security considerations apply. From the point of view of the receiving context, the IOR is a “normal? object
reference. No “special? rules, with respect to security or otherwise, apply to it. The fact that it is ultimately a reference
to an implementation that was created from instantiating and registering an value type implementation is not relevant.
In both of these cases, security considerations are involved with the decision to allow the ORB-mediated invocation to proceed.
The fact that a value type is involved is not material.