OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] Re: Minutes of Feb 18 Policy model subcommittee concall


On Thu, 21 Feb 2002, Sekhar Vajjhala - Sun Microsystems wrote:

> > * [line, 130, subject] change to "the entity that submits access
> >    requests"
>
> How about "an entity that is the source of an access request" ?
>
> The interpretation of the source is from the point of view PDP.
> So it could be the "initiator" or the "intermediary".

Well, the subject could also be both the initiator AND the intermediary
together.

I would tend to use relative definitions since subject is one of the
inputs of the policy evaluation, instead of trying to leverage higher,
lofty concepts.  Let's be specific to the document and its application.
What we really want to show is how all the inputs are related to each
other so that the policy will evaluate to the correct answer. So, my
proposal:

Policy: A function from Subject, Resource, and Action to an Access
        Decision of Permit, Deny or Indeterminate,  (such that)

Subject:  The entity that is to perform an Action on a Resource.
Resource: The entity on which the Subject is to perform an Action.
Action:   The operation on a Resource that the Subject is to perform.

Since we have Subject X Target semantics and we use Target to define
applicability,  we define:

Target:   An entity that comprises a particular Resource and one of
          its Actions.

This language is kind of self-contained and shows specifically each
element and how it relates to each other without an appeal to some higher
concept of what each element may be in some instance.

I guess what I mean is that these terms are specific to this document and
not to notions of govern, source, submitting access requests, all
which, I think are really out of scope.

The application of a PDP, i.e. a PEP, would then know then that it must
assemble a Subject, a Resource, and an Action based on their relative
definitions to get back a proper Access Decision. That is it, plain an
simple. What the PEP or anything else does with the results is out of
scope. As long as the PEP or anything else gives the PDP a properly formed
Subject, Resource, and Action, it will get the correct Access Decision
back based on the policy function set at the PDP.

So, my proposal is to word the glossary as such.

Am I totally off base, here?

Cheers,
-Polar


> Sekhar
>
>
> Pierangela wrote:
> >
> > MINUTES OF THE POLICY MODEL SUBCOMMITTEE (MONDAY, FEB. 18 2002)
> > ===============================================================
> >
> > PRESENT
> > * Anne Anderson (Sun)
> > * Carlisle Adams (Entrust)
> > * Ernesto Damiani (Unimi)
> > * Simon Godik (Crosslogix)
> > * Polar Humenn
> > * Michiharu Kudoh (IBM)
> > * Fred Moses
> > * Pierangela Samarati (Unimi)
> > * Donn Flinn
> >
> > ---------------------------------------------------------------
> >
> > We went over Tim's document, below is a summary of the points we
> > touched and corrections requested to the document (points requiring
> > corrections are anticipated by *). Summary of discussion or
> > explanation is in the NOTE following each point.
> >
> > * [line 98, access control] ``with policy'' change to ``with a
> >   policy''
> >
> > [line 100, Attribute] Donn notes that it seems a circular
> > definition. Everybody agrees but it is also noted that this there
> > seems to be no better way to define it.
> >
> > * [line 102, authorization decision] ''of policy'' change to ''of a
> >   policy''. Also ``BOOLEAN range'' change to
> >   ``permit/deny/undetermined''
> >
> > * [line 109, meta-policy] ''combining rules'' change to combining
> >   rules or policies"
> >   NOTE: A metapolicy can state how you should combine classes of rules
> >        or of policies. For instance, it could query attributes of
> >        rules (e.g., sign) or of policies (corporate policies as
> >        opposed to department policies). Simon notes there are two
> >        components. one is how to solve conflicts, you do not really
> >        need this syntax. The other level is when you start combining
> >        policies, here you need the expressive power of the metapolicy
> >        language. So for meta-policies associated with elementary
> >        policies we could have a pre-defined URI expressing the
> >        conflict resolution policy without need to use the metapolicy
> >        specification language. It is however noted that at the URI you
> >        should find a metapolicy expressed.
> >
> > * [line 110, meta-policy-one] Question: do we want it?
> >   NOTE: We once said it would be nice if we had at least an example of
> >         meta-policy in our proposal. Should we have it explicitly
> >         mentiones ``meta-policy one''?
> >
> > * [line 111, policy] Change the entry to say ``Applicable policy''
> >   also add in the definition ``plus a specification of how to combine
> >   them''
> >   NOTE: The current definition sees policy from the PDP point of
> >         view. It is noted that there is another point of view with
> >         which to look at policy: the policy writer point of view. If,
> >         as a department, I specify certain authorizations, to me that
> >         set is a policy even if it not complete w.r.t. an access
> >         decision (since there are corporate authorizations to be
> >         enforced also, and even if it refers to more than one access.
> >         It is suggested to capture both view point by distinguishing
> >         the definition of ``policy'' (point of view of the policy
> >         writer) and ``applicable policy'' (point of view of the PDP).
> >
> > * Add definition of ``Policy'' as ``A set of rules or an expression of
> >   policies with associated a specification of how to combine them
> >   (metapolicy)''
> >
> > * [line 112, PAP] ``rules'' change to ``policies''
> >   Note: the administrative unit is the policy, not the rule
> >
> > * [line 118, PRP] ``creates policy from rules'' change to ``creates a
> >   policy from "from component policies or rules"
> >
> > * [lines 127&128, Role and role mapping] Remove
> >   NOTE: we do not support roles in a traditional sense of RBAC access
> >         control. Also it is not clear if the clear separation between
> >         groups and roles that holds in traditional context (role is
> >         set of privileges and is dynamic, group is set of people and
> >         is static) would apply in our open scenario (for instance
> >         ``Oasis member'' expresses a group or a role concept). Donn
> >         suggests not to put such concepts in the glossary. It is
> >         however agreed that roles and groups and important concept in
> >         access control and we should mention them and how we are able
> >         to support them. It is agreed to
> >
> > * add the mention to roles and groups in Section 1.2- related terms
> >   and say that they are we support them through SAML assertions (that
> >   can state that a subject enjoys some roles or belong to some groups).
> >
> > * [line 129, rule] It is agreed that it will need to be redefined,
> >   the definition is postponed to after the model discussion (so we
> >   will have agreement of how a rule looks like)
> >
> >   NOTE: Michiharu notes there is no rule element in the XML
> >         examples. Ernesto replies that there need not be, there is a
> >         rule type, you can call the elements how you want.
> >
> > * [lines 136&137] To be rephrased as they are not correct.
> >   NOTE: It's true that we are not using those terms but they are not
> >         attributes
> >
> > * [line 138] We use subject (in line with SAML) not principal.
> >
> > * [line, 130, subject] change to "the entity that submits access
> >    requests"
> >   NOTE: The definition as it is now is not informative. it is noted
> >   that the new definition proposed may not be comprehesive of all
> >   possible cases. For instance, there is the multiple subject
> >   examples: a patient asks the system to send its data to a
> >   doctor. Our subject will be the patient, how do we capture the
> >   doctor? Also, there is the case of objecty-oriented or Java based
> >   policies where you may need to consider which method called which
> >   method or consider the different parties (e.g., caller and owner) of
> >   a piece of code. Michiharu asks if we should capture the concept of
> >   a "initiator" (similar to multiple subjects, e.g. object oriented
> >   where a method delegate to another for making a request...)  It is
> >   proposed to keep the simple definition for now (to arrive to version
> >   1) and work later on possible extensions. Our version 1.0 should be
> >   able to satisfy functionalities for a number of cases and
> >   environments.  The ones that are not covered are to be taken as a
> >   basis for extensions. Ernesto notes that not supporting the cases
> >   for Java and o-o scenarios may result limiting.
> >
> > * mention the concept of ``requestor'' and ``initiator'' in Section
> >   1.2 - related terms
> >
> > * [line 131, target] Add ``A boolean expression on subject, resource
> >   and action that defines'' at the beginning.
> >   NOTE: Is the target really stated as such an expression (cf. F2F)
> >
> > * [page 17, line 630] target refers to the old definition (should be
> >   updated). Also, element name applicable policy should be changed to
> >   policy statement.
> >
> > Still pending concept we would like to convey but probably later in
> > the document reported here to remember it is that ``a policy is a
> > smallest unit that can be solved by the PDP'' (Simon ``a policy is the
> > smallest exportable unit -- i.e., the one on which you can define
> > combination (you do not combine rules but policies)
> >
> > In the concall we went over section 1. Rest of the document for next
> > concall (Monday Feb. 25, 2002).
> >
> > best
> > -p
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> --
> Sekhar
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC