Dear colleagues,
below are some comments on the draft v.7 that Tim circulated inserting
the policy committee working document into the complete saml document.
Also below are some comments on the comments that have already been
circulated on v.7.
I'd like to go over all this (and then to other comments i might have
missed or that any of you might have) together with you at the concall
tonight to reach a consensus of the subcommittee of the different issues
that we have brought up for discussions. for many points i think
discussing by voice at the concall is better than having back and
forth by email.
I hope we will be able to discuss all the matters in a constructive
way (as it was the case for many of the pleasant and productive
concalls we have had in the past)
talk to you later
best
-p
P.S. no need to read all this before the concall (which will be in
three hours, but it would be nice if you could have this and the
exchanged msgs handy)
================ Comments on the draft=========================
page 3,line 62: applicable policy. As it is stated it seems to assume an
indicization w.r.t. the resource, which i think it was nevert
page 3,line 68 : "classification", is this the set of attributes
associated with objects (equivalent to SAML assertions for principals)
page 3, line 69: notion of context not clear.
page 3, line 75: about the definition of policy. I believe that it was
agreed to term as "policy" a set of access control rules. Why is
policy pointing to applicable policy?
page 3, line 78: Definition of PDP not clear to me. Is it intended to
mean that the PCP determines which rule constitute the applicable
policy w.r.t. a request
page 4, lin1 84: what does it mean for the applicable policy to be
complete? shouldn't PRP be defined as the entity that retrieves all
the rule applicable to a given request (note request, not resource)
page 4, line 92: about the definition of principal. Shouldn't it be
explicitely defined as the "entity requesting access"? The definition
at line 92 could match anything (even a resource)
page 4, line 94: definition of role. I believe we discussed this in a
couple of telecon and this was not the definition i recall.
Why would we need the definition of role this way?
page 4, line 95: definition of rule. I remember again a discussion at
a telecon (Nov. 19) where participants agreed that they did not agreed
on the definition of rule. It was said we should have talked with Tim
(Moses) about this but at the last telecon there was no possibility of
any discussion.
page 4, line 100. I do not believe the term attribute is used in
places of privilege, permission, right, and authorization.
page 4, line 102: the terms subject and user although often used as
synonims if the terminology is clarified beforehand are a different
concept. It is not clear whether with this sentence we want to mean
that principal is used in place of user.
page 4,line 106. Role vs group (this is an open matter for discussion
i believe). Also w.r.t. the definition given for roles (line 95)
page 5, line 137: "PRP returns the policy" shouldn't it be the
*applicable* policy? or are all the rules passed along?
page 5, lines 138-141: related also to the previous point. The
applicable policy should depend on the evaluation of conditions on the
attributes, are rules for which conditions cannot be evaluated
considered part of the policy that is passed along?
page 5, line 146: "policy instance", i do not think it has been
defined.
page 5, line 148: "if the policy were to evaluate to TRUE" there seems
to be a gap here as it is not defined when a policy evaluates to
TRUE. I do not comment on post-conditions as the discussion is still
open.
page 13, lines 334-335: not completely clear. Also, it is not clear
how the discussion in this paragraph relates to the notion of role as
given in the glossary. Role was defined in the glossary as a set of
attributes (although i do not think this is the definition we have
assumed in the policy committee telecons), line 335 state "role may
have attributes. ????
page 14, line 355: classification can have attributes? wasn't it
defined as set of attributes? Can a resource have different
classifications (each stating a set of attributes)? from the glossary
and the examples it is not clear what we are assuming. Classification
seems also to be used to denote groups (line 386-387: "resource
... belongs to the classification")
page 15, line 396. "each rule is composed of a pre-condition and zero
or more post-conditions
page 5, lines 395-400. seems ok but it is a generic statement that i
think we will need to investigate more.
===================== end comments on the document =================
==================== responses to earlier postings =================
(in order of date and stating the sender, my comments are indented)
TIM MOSES:
Line 163 - Policies will commonly evaluate attributes of a principal,
or set of principals, not merely its identity.
there is no statement about identity, the principal expression
is a boolean expression over principal's attributes
Line 165 - Allowing dynamic actions seems unnecessarily complicated.
these are not dynamic actions are expressions over action. ok,
if we want to have an explicit action stated. What that line
was meant to state (probably is was not stated well) was that
like for principals and resources, the actions on which a rule
applies are stated as expressions. I think these feature was
useful to express conditions on action's parametes. Some
example of conditions we may want to have on action parameters
are also constraints on the recipients of some data was (see
Fred example)
that policies are identified with the resource action and resource
classification, meaning that this information is contained in the
policy instance, and used to identify the policy, for purposes of
locating, retrieving and verifying it. This solution is impacted if
actions are dynamic.
well reading the first part of the draft and the glossary it
seems you index on the resource rather than on the action. In
any case even for the resource we have this problem then (and
i believe in previous concall we were working under the
assumption that a rule is *not specified for a single
resource* but for a set of them (those that match the resource
expression)
Line 168 - PDPs may also execute some post-conditions.
post-conditions were not clear in the draft as they have not
been discussed yet
Lines 179-181 - Figure 2 accommodates this requirement by identifying
separate types for role, classification and environment attributes.
not clear what you mean by this, we can clarify at the concall
tonight
Section 3.2.3 - Figure two provides a solution without differentiating
between expressions for principals, resources and environment. Some
policies will require comparison between attributes of principals and
attributes of resources. So, separating expressions for principals
from expressions for resources does not seem helpful.
it is true that you can see everything as a single combined
expression. Seeing them separate was for clarity. It is true
that some expression will need to evaluate attributes of
principal and reources in relationships (e.g., the example we
have mentioned few time about a rule stating that ``users
can access the object for which it is owner''). in the
assumption we were making the principal expression would
contain only conditions on principal atrtributes while the
relationship between the resource attribute and the principal
is stated in the resource expression. In any case seeing them
as a single complex expression or separated does not make much
difference w.r.t. expressiveness.
Line 187 - Contains a new definition for "role", vis "privileged
position".
postponed to the discussion on roles we are having
Section 3.2.5 - It is better to make the parameters attributes of the
resource, not the action. Otherwise, a different solution for binding
policy to the saml authorization query must be devised. In the
example given, the resource can be the "withdrawal", with attribute
"500,000", then the action can be "withdraw". The policy can then be
bound to the resource "withdrawal" and the action "approve".
not clear. how do you translate parameters of the action to
parameters of the resource?
Line 243 and on - According to the explanation of Figure 2, rules must
be logically combined in policy. They are not merely "listed". This
removes any ambiguity about combining rules.
what do you mean by ``logically'' combined? logically combined
means taking the OR of the rules, the discussion claims that
that is not enough. The distinction about restrictions and
authorizations (which is still at the preliminary discussion
was to avoid negative authorizations, see discussion we had
about negative authorizations)
Line 300 - Dynamic conditions are accommodated in the model using
"external functions".
postponed again, better discussed by voice.
Line 301 - Post conditions are accommodated in the model.
postponed again, better discussed by voice.
Line 302 - Content "introspection" is accommodated in the model for
both XML documents and non-XML documents. In the former case, the
resource attribute contains an XPath expression into a document of the
specified type, it being implied that the instance referred to is the
one identified by the saml authorization query. In the latter case,
the resource attribute contains an XPath expression into a saml
attribute assertion, probably issued by the PEP and containing
attributes of, or values from, the resource.
i am not completely sure about this, postponed again, better
discussed by voice.
Line 313 - This is dealt with in Figure 9.
discuss in telecon
================================================================
HAL LOCKHART
First of all, I have already conceded that we probably need negative
rules, so lets not argue about that.
i think we are still discussing whether to have negative
authorizations or not. When i first mentioned negative
authorizations you had a very strong reaction and responded
``Anybody who has worked in operational security for any
period will tell you that negative controls should be avoided
like the plague.'' as i said i that time i did not agree with
your statement. i do agree however on the fact that negative
authorizations do definitely bring complications.
One thing that concerns me about your example is that it is a
completely different problem space from any of our use cases. Now I
am not trying to disqualify it on a technicality, but I do have a
concern that it may represent a problem that is outside of the scope
of XACML. Someone (not me of course) might argue that filtering emails
is more like doing a text search or a database query than creating a
policy model. Can you recast the example in one of the use case
problem domains, such as medical records or XML documents?
Alternatively, would you like to submit a usecase around filtering
SPAM?
Bill examples were referring to email filtering but you can
imagine similar examples to block access to your resources
(e.g., for the .htaccess file you specify to protect web
pages)
This seems problematic to me, particularly in situations where
policies relating to a particular access request are generated by
several individials independently. But I have not read her paper
completely or thought about it carefully.
again it was an attempt to avoid negative authorizations for
which it seemed there was strong feelings against. We can (i
hope) discuss this better in the telecon.
=================================================
HAL LOCKHART
The general problem being discussed is that many existing accesss
control systems imbue certain attributes with special semantics. In
contrast, X.509 and SAML, for example, consider that attributes are
just name value pairs and special semantics are up to the
implementation. Examples of special semantics include: clearances,
nested roles and dynamic roles.
I feel compelled to point out, in passing, that the the hierachy
represented by clearances and the hierarchy represented by nested
roles (groups) are completely different from each other.
agreed. i believe that the hierarchies Simon (Godik) has been
referrin to in our concalls where simply the groups and roles
hierarchies (we have never been talking about multilevel
access control)
============================================================
HAL LOCKHART
We need to decide as a matter of terminology, whether the decision to
allow or prohibit access is considered one of the post conditions
(presumably mandatory) or is it considered a seperate thing?
Personally I don't feel strongly either way, but I would like to be
clear on what is meant when the term post conditions is used.
i believe post-conditions (whose current definition was said
should have been revised in the policy subcommittee concall of
Nov. 19) should simply report (if any, and if we want them)
the actions not the decision
==========================================================
TIM MOSES
In one view, there should be a prioritization of the evaluation of
policies that hook nodal operations. This is extremely important,
since a post-condition could cause the short-circuiting of parsing of
the sub-tree under a particular node; one would therefore want
higher-priority policies to evaluate before lower priority. Also, if
certain policies set attributes that affect the outcome of other
policies, one would want those to be of higher priority.
if we go towards this we open a can of worms with lots of
complications (see treatment of triggers in active database
systems). in the concall of Nov. 19 it was said that most
probably we do not need such a heavy focus on postconditions,
but this again still has to be discussed
==================================================
MICHIHARU KUDOH
Here are my comments on draft 0.7.
Line 131-136 - Are resource classification and the requested action e=
nough to identify the applicable policy? I agree that in most cases
the res= ource classification and the requested action are used. But
there is the ca= se that the applicable policies are classified by
subject attribute, for example, the policy for US citizens and the
policy for not US citizen= s. In that case, there may be no need for
specifying any resource classific= ation. Thus , my suggestion is to
add something like "principalClassificatio= n" to the "applicability"
element and changes minOccurs attribute to "0" fo= r all element under
"applicability".
agree
I think that is right. You are considering the most complicated policy
that allows post-conditions as well as positive and negative
permission. [deleted stuff]
probably it is better to discuss in the telecon
=====================================================================
TIM MOSES
Hal - My view is that the PDP won't necessarily evaluate all rules.
If it determines that the policy evaluates to true regardless of the
condition of some (as yet) unevaluated rules, then it should go ahead
and return a "permit" status code. All post conditions associated
with rules that were required to evaluate "true" for the policy to
evaluate "true" must be executed.
agree that if you can take a decision based on something you
have you can go ahead and take it. do not think it works
though in the case you have not only permissions (e.g., you
have negative rules or restrictions) and you have
postconditions (which we still have to discuss)
==========================================================
HAL
It just occurred to me that there is a substantive question related to this.
Currently, a policy conflict occurs when you have 2 or more rules and they
get different answers.
we have not defined what it means to have different answers
yet (as we have not defined answers yet). again probably many
of the last points will come straigtforward once we have
clarified the type of rules we have and how we deal (if we
have) with postconditions
===================================================================
TIM MOSES
Colleagues - I have gleaned the following six issues from the mail
list. I suggest we devote approximately twenty minutes to each of
these topics during our telecon on Monday. [deleted stuff]
taken note will discuss at the telecon tonight
==============================================================
HAL
I hadn't thought about that one. What you say is logical, but I suspect
people will find it unintuitive and perhaps unacceptable. This poscondition
stuff is a minefield. I need to think about this more.
agreed
===============================================================
TIM
You propose adding a capability-style model, in addition to the
access-control-style model that is currently described. It was my
understanding that we decided to avoid the capability-style of model =
early on. However, even if my recollection is correct, it is possible
that= we made that decision without full consideration of the
consequences. S= o, I have included the topic in the list of issues
for discussion on Monda= y.
i have the same recollection as michiharu, we never committed
to ACL style (and explicitely stated few times that a rule may
refer to a set of resources), i recall we had discussion about
indexing....
talk to you later