Title: RE: Policies with No Subject
Colleagues - I strongly support Hal's view.
(His
third paragraph does contain an implicit definition of the term
"privilege" which conflicts with my use of the term. But, that
is not material to this discussion.)
I
envisage XACML 1.0 defining informative "bindings" for some common
policy distribution mechanisms (the Web, ODBC, LDAP) that explain how to locate
and retrieve the XACML policy statement for a specified resource/action
combination. So, the schema of this mechanism will probably be based on
the structure of resources and their actions. The policy statement will be
executed by an XACML virtual machine, the operation of which is defined in the
one normative XACML meta-policy. The virtual machine must obtain just the
parameter values indicated in the policy statement. These may include
attributes of the subject, but they don't have to.
If a
parameter is not included in the policy statement, then it does not have to be
considered in the policy evaluation.
All
the best. Tim.
-----------------------------------------
Tim Moses
Tel:
613.270.3183
-----Original Message-----
From: Hal Lockhart
[mailto:]
Sent: Thursday, September 20,
2001 11:15 AM
To: 'Ken Yagen';
Subject: RE: Policies with No
Subject
I
am working on a paper that will describe my ideas more fully, but briefly
here is the argument.
Policy evaluation has two phases. 1. identifying
the policies that apply to particular request 2. execute the policy
evaluation algorithm
There is a somewhat arbitrary choice of which
inputs to apply to each phase. However, since resources are distributed and
control is federated it makes sense to organize them by the resources they
apply to, so that they can be located physically close to the resources and
their administrators. This suggests that resource and closely related items
such as action must always be specified, so it is possible to determine
which policies apply.
Privilege is something I consider to be
completely synthetic and may not necessarily even be present in a
policy model at all. For example, the AssureAccess policy model does not
currently contain the notion. We map to resources and actions. Privilege, as
it is typically used, is actually a target aggregator, in the same way group
is a subject aggregator. A priviledge is a shorthand name for some
collection of resources and methods that are considered to be similar from
an access control perspective.
Hal
-----Original Message-----
From: Ken Yagen
[mailto:]
Sent: Wednesday, September 19,
2001 7:54 PM
To:
Subject:
RE: Policies with No Subject
I was not at the F2F and did not hear the discussion,
but I wouldn't think it to be too unreasonable to consider subject
differently than location, time, and other policy variables. Along the
same lines you could frame arguments that privilege and resource are not
necessary. You can have a user or role that have access to all resources
or can perform any kind of transaction with a particular resource. I
think it is pretty well accepted that there are a lot (but not all)
policies that refer to a subject and that makes it important enough to
be considered as a required part of the policy language.
Ken Yagen
Director, Software
Development
CrossLogix, Inc
www.crosslogix.com
-----Original Message-----
From:
Hal Lockhart [mailto:]
Sent: Wednesday, September 19, 2001 2:26 PM
To:
Subject: Policies with No Subject
At the F2F I asserted that a policy could contain zero
or more subjects. The
use of a policy with zero
subjects was questioned. My answer was that if the
policy did not consider any information about a subject, there
was no need
for a subject in the policy. For
example, if the policy says the resource
can be
accessed between 24:00 and 6:00, there is no need to specify a
subject.
At the meeting several people agreed that in a case like
this, there would
still be a subject. There
would be some kind of indicator that it applied to
all subjects, such as "*" or "ALL". I
conceded this possibility at the time
and the
discussion turned to other topics.
I now believe that this is illogical. I assume that
policies can take as
inputs items such as the
date and time, network location, method of
authentication and so on. Therefore, if a policy that does not
consider
subject information must contain
"all subjects" then logically a policy that
does not consider time must contain "all times", a
policy that does not
consider location must
contain "all locations" and so on.
This would obviously cause every policy to become
encrusted with useless
junk. I think it is
clearly much simpler to put into each policy just the
items that need to be evaluated and leave out the others. The
point is that
I consider subject to be just one
type of input that may or may not be used
for
policy decisions.
Hal
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
