What are the semantic connotations for rights in CORBA
rights family?
- 1 Answers
- 3495 Views
- I also Faced
- E-Mail Answers
Answer Posted / rithi
Extended Question
Gerald Brose: ``The Security Service Specification (Rev
1.2) specifies an default access control policy. This policy
uses "rights" for authorizations. Also, a default rights
family "corba" for use with the domain access policy is
defined (p.15-124) that has rights (s,g,m,u) for set, get,
manage and use. The option of defining new rights families,
is severely limited by the definition of rights families as
structs, and is explicitly discouraged in the spec. to keep
things simple.
Actually, I think this is absolutely inappropriate, but
I might be missing the essential points that justify this
design. My question therefore is:
Given that the corba rights family is intended to serve
most cases, what exactly are the semantic connotations for
these four rights? Are they simply chosen in an ad hoc way,
or is there some deeper reasoning behind this choice, such
as why it would make administration easier in some cases? If
so, how and in which cases?''
Bob Blakley (April, 1998):
This is a good question, and one which we discussed
extensively during the initial definition of the
specification. The basic motivation for defining a small,
standard set of rights and strongly encouraging everyone to
live with that set is that there are a potentially unlimited
number of methods in any given CORBA system (each new class
can introduce large numbers of them), and the set of methods
is semantically very complicated from the viewpoint of the
administrator - methods with the same name may do different
things, methods with different names may do the same thing,
methods may have names which do not at all suggest their
function or sensitivity, and methods belonging to the same
class may have very different consequences if invoked on
different instances with different internal states. This
makes it almost impossible for administrators to manage
policy using methods. Rights are thus introduced as a way to
"group" methods. We could have stopped after introducing the
notion of rights, and allowed implementors or even
administrators to define arbitrary collections of rights,
but we felt that this would lead to a chaotic situation in
which the population of rights would be widely variable
across different vendors' implementations and different
customers' or even departments' deployments, making training
and interoperability a nightmare.
We chose instead to conceive of rights as a kind of
language, to be used definers of new object classes to
communicate the sensitivity of their classes' methods to the
security administrator. We defined a small language of
rights which corresponded generally to the KINDS of
operations which an object-oriented system's methods
perform, namely:
method reads and returns one of the object's data members
method writes one of the object's data members method
executes one of the object's member functions
We defined a right corresponding to each of these basic
KINDS of operations, and added one more right to deal with
the real-world fact that some operations of the same KIND
are more sensitive than others of the same KIND.
Hence the intended semantic connotations of the rights in
the "corba" family are:
s ("set"):
required to access methods which modify an object's
internal state (e.g. setter methods for data members)
g ("get"):
required to access methods which return, but do not
change, an object's internal state (e.g. accessing readonly
attributes or other data members; getter methods)
u ("use"):
required to access methods which perform computations or
call other objects (e.g. member functions)
m ("manage"):
required, usually in addition to one of the other three
rights, to access methods which perform management
activities, are unusually sensitive, or are otherwise
intended for use only by specially privileged callers.
Note that these semantics are NOT "exact" in the sense that
they have neither formal nor normative definitions.
Nevertheless, I think it's quite clear to both class
definers and system administrators what they are supposed to
mean, and how they can be used.
Clearly they aren't an exact match for all possible security
policies in a CORBA environment, but I don't think a system
which supports an exact match for all possible policies
would be one which could be administered by normal humans.
| Is This Answer Correct ? | 0 Yes | 0 No |
Post New Answer View All Answers
Can corba application have call back?
Can corba allow servers to cause client side events or notifications?
Explain does corba support distributed reference counting architectures?
Can corba application be multi-threaded?
Can corba application be tuned for better performance?
Explain does corba define high level application architectures?
How to implement the CORBA security service?
Compare CORBA security with security of other distributed object computing frameworks such as Java RMI or DCOM?
What would be the most suitable ORB products when buliding a small lab for evaluating, testing and implementing security functions in a CORBA system?
What about CSI with SSL?
Are CORBAsec implementations from the US generally subjected to export control?
Explain high-level technical overview of corba?
Does corba supports asynchronous communication?
Explain the reason to implement a corba application with multi-threading?
What are the reason to avoid the development of multi-threaded corba application?
