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: [xacml] XACML F2F March 11, 2002 Minutes


Title: XACML Conference Call Minutes
Here are the formatted minutes. Text is really unchanged from Anne's minutes already sent out. Carlisle did post some comments on the minutes which I have not included yet, but if there is agreement to make the changes Carlisle suggests, I will update the minutes.

XACML Face to Face #4

Date:  March 11/12, 2002

Location: Burlington, MA (SUN)

Minutes of Meeting

(Minutes taken by Anne Anderson, Edited by Ken Yagen)

 

Contents

  • Votes
  • Proposed Agenda
  • Roll Call
  • Action Items
  • Summary
  • Agreements Reached
  • Deferred Issues And Questions
  • Detailed Notes

 

 

Votes

?

 

Proposed Agenda:

Monday, March 11th

9:00 a.m. - 5:00 p.m. (or later):

   - aside from roll call, etc., for the first 10 minutes or so, we take as much of the day as necessary to come to consensus on the definition and high-level contents of

         RULE,

         ("basic" or "elementary") POLICY,

         ("compound" or "higher-level") POLICY, and

         META-POLICY

   - breaks:  roughly 10:30-10:45;  12:00-1:00; 3:00-3:30

   - be prepared to camp out in the Sun conference room if necessary.  I would really like these basic definitions to be closed before we adjourn on Monday.

 

Tuesday, March 12th

 

9:00-10:30:    Post-conditions / Obligations discussion (led by Michiharu)

10:30-10:45:  BREAK

10:45-11:15:  Post-conditions / Obligations discussion

11:15-12:00:  Arithmetic Operators discussion (led by Ernesto or Tim)

12:00-1:00:    LUNCH

1:00-2:00:      Extensibility discussion (led by Simon)

2:00-3:00:      Use Case discussion (Michiharu on protecting XML resources; Sekhar or Simon on J2SE; any others?)

3:00-3:30:      BREAK

3:30-5:00:      Resolve as many remaining issues from the Issues List as practical

5:00:              Adjourn

 

Roll Call

Voting Members

Simon Godik, Self

Hal Lockhart, Entegrity

Carlisle Adams, Entrust

Tim Moses, Entrust

Don Flinn, Hitachi

Michiharu Kudoh, IBM

Bill Parducci, Self

Polar Humenn, Self

Sekhar Vajjhala, Sun Microsystems

Anne Anderson, Sun Microsystems

 

By Phone

Pierangela Samarati, Univ. of Milan

 

Probationary Members

Konstantin Beznosov, Hitachi

 

ACTION ITEMS:

 

[Tim] Update specification to Version 11, incorporating decisions from this meeting.

[Tim, Michiharu] Propose specific set of mathematical operators and associated syntax appropriate for XACML requirements.  Present at the subcommittee meeting on March 25, 2002.

[Hal, Konstantin] Provide more verbal text describing function and use of the various element types.  To be done after Tim provides Version 11.  The verbal text might be a type of "primer" on XACML; something to introduce XML neophytes to the way the language is intended to be used.

[Carlisle] Determine availability of sites and dates for next face-to-face meeting.  Date preference order: week of April 15, week of April 22, week of April 29.  Location preference order:

  1. Univ. of Milan (Ernesto,Pierangela)
  2. SF Bay area (Ken)
  3. Manhattan Beach (Bill)
  4. Burlington (Anne, Sekhar).

Constraints: Michiharu not available week of April 29.  Sekhar has problems with weeks of April 15 or April 22.

[All] Determine acceptability of Univ. of Milan as a site for the next face-to-face meeting.

 

 

SUMMARY:

 

We resolved most issues related to the overall policy model.  The following chart lists overall areas that are still OPEN, those on which we are in AGREEMENT, and those where we have done some work, but need more work (?).  Most of the OPEN areas have to do with details of the XML syntax rather than the policy model itself.

 

Operators

Boolean

? [1]

 

Math          

OPEN

Predicates       

Predefined

? [2]

 

Definition    

OPEN

Values           

Boolean 

? [1]

 

Math          

OPEN

 

SAML:attribute

OPEN

Expression       

Boolean       

? [1]

 

Math          

OPEN

Condition                       

 

? [1]

Obligation                      

 

AGREEMENT

Obligation arguments             

 

OPEN

rule

ref           

AGREEMENT

 

statement     

AGREEMENT

ruleCombiner                    

 

OPEN

ruleSet                         

 

AGREEMENT

policy           

ref           

AGREEMENT

 

statement     

AGREEMENT

 

saml:assertion

AGREEMENT

policySetCombination            

 

OPEN

policySet                       

 

AGREEMENT

policyCombination

ref           

AGREEMENT

 

statement     

AGREEMENT

 

saml:assertion

AGREEMENT

[1] We have not written out and agreed upon Boolean expressions, but we expect we are in agreement modulo nits.

[2] We have discussed some predicates that would be predefined, but there is more closure required on this.

 

AGREEMENTS REACHED:

 

Three major elements from which a policy is constructed:

1. low level <rule>s,

2. <policyStatement>s that combine rules, and

3. <policyCombinationStatement>s that combine policies.

 

<rule>

  <target>

    <subject>..</subject>

    <action>..</action>

    <resource>..</resource>

  </target>

  <ruleMetaData name="anyURI" value="any"/>

  <condition>

    [arbitrary boolean predicate over subject, action, resource]

  </condition>

  <effect>..</effect>     [CHOICE: Permit or Deny]

  <obligations>           [OPTIONAL]

    <obligation>

    <obligation>

    ...

  </obligations>

</rule>

 

<target> allows efficient indexing.  <target> MUST contain only references that will always be available in the SAML request because the <target> MUST NOT return an "indeterminate" result.

 

Another reason for requiring <target> references to be readily available is to support the use of <target> for efficiently eliminating clearly inapplicable <rule>s without requiring

extensive evaluation.

 

A <rule> can produce one of three possible results: grant/deny, inapplicable, indeterminate.  The same <rule> will never return "grant" from some  <authorizationDecisionRequests> and "deny" from others: a <rule> has a single associated <effect> and either returns that one effect or inapplicable or indeterminate.

 

The <condition> element participates equally with the <target> element in determining the applicability of the <rule>.  <target> is the easily-computed first stage, and <condition> is the arbitrarily complex second stage.

 

<rule> Truth Table:

 

Target 

Condition

Effect

-------

------------

--------------

T        

[Effect]

F       

Inapplicable

Indet.

Indet.

T       

Inapplicable

F       

Inapplicable

Indet.

Inapplicable

 

Scope of <rule> does not go beyond the <policyStatement> that references it.

 

Policy is smallest unit that can be signed.  Rules can stand by themselves, but can't be signed.  Policy can include a hash of the actual syntax content of a <rule>.  In this case, the policy writer wants this particular <rule> content.  If no hash, then then policy writer wants current rule associated with this <ruleId>.  Example: a <ruleId> may be associated with the semantic "conditions under which someone is allowed to access Anne's files".  Anne may change the specific conditions over time, but might retain the same <ruleId> so that the current rule can be referenced in a policy without having to rewrite the

policy.

 

<policyStatement> extends saml assertion:

  <MajorVersion>

  <MinorVersion>

  <IssuerInstant>

  <Issuer>

  <AssertionId>

 

<policyStatement>

  <target>

    <subjects>

    <resources>

    <actions>

  </target>

  <ruleSet Combiner="myURI">

    <ruleDesignator>

      <ruleMetadata>

      <ruleReference> or <ruleInstance>

    </ruleDesignator>

    <ruleDesignator>...</ruleDesignator>

    <obligations>

      <onPermit>

        <obligation uri="myobligation1" value="abc"/>

        <obligation uri="myobligation2" value="cde"/>

      </onPermit>

      <onDeny>

        <obligation>

      </onDeny>

    </obligations>

  </ruleSet>

</policyStatement>

 

<policyStatement> Evaluation Table:

 

  Target   RuleSet   Result

  ------   -------   --------

  match    [effect]  [effect]

  match    Inappl.   Inappl.

  match    Indet.    Indet.

  no-match           Inappl.

 

  <ruleReference uri="http://..."

           authority="..."

           hash="..." [OPTIONAL: only if ruleId content must be fixed]

  </ruleReference>

 

A <ruleSet> is a set of <rule>s along with a way to combine the rules.  A <ruleSet>s "combiner" is a URI associated with a description of the algorithm for producing a result from the given set of rules.  The "combiner" MAY be a textual description.

 

Examples of possible <rule> combiners:

o If any <rule> evaluation returns "inapplicable", "deny", or "indeterminate", return "deny".  Otherwise, return "permit".

o If any <rule> evaluation returns "deny" or "indeterminate",  return "deny".  Otherwise, if at least one <rule> evaluation returns "permit", return "permit".  Otherwise, return    "inapplicable".

o Return effect of the rule whose <target> "most closely matches" the request (for some definition of "most closely matches").

o Return effect of first rule from list that returns "permit" or "deny".

 

<policyCombinationStatement>

  <target>

    <subjects>

    <resources>

    <actions>

  </target>

  <policySet Combiner="myURI">

    <policyDesignator>

      <policyRef> or <policyStatement> or

        <policyCombinationRef> or <policyCombinationStatement> or

        <saml:assertion>

      <policyMetadata>

    </policyDesignator>

    <policyDesignator>...</policyDesignator>

    <obligations>   OPTIONAL

      <onPermit>

        <obligation uri="myobligation1" value="abc"/>

        <obligation uri="myobligation2" value="cde"/>

      </onPermit>

      <onDeny>

        <obligation>

      </onDeny>

    </obligations>

  </policySet>

</policyCombinationStatement>

 

The <policyCombinationStatement> "combiner" is a URI associated with a description of the algorithm for producing a result from the given list of policies.  The "combiner" MAY be a textual description.

 

If you want to select policies based on data other than <target> and <ruleSet>, then you have to embed policyStatement in SAML assertion.  Then the "combiner" can select on things like the issuer of the policy, whether policy is signed, etc.

 

We may decide for simplicity to remove some choice options from <policyCombinationStatement> in Version 1.0, but we are going to leave it all in for now and flesh it out.

 

We will use the term "obligation" to mean what we have previously been calling "post condition".

 

An Obligation is specified via URI and optional value attribute.

 

 <policyStatement>

   <target>

     <subjects>

     <resources>

     <actions>

   </target>

   <ruleset>...</reuleset>

   <obligation>

     <onPermit>

       <operation uri="http://www.xyz.com/obligation/log"

            value="abc" />

     </onPermit>

   </obligation>

 </policyStatement>

 

The set of <obligations> returned by each level of evaluation includes only those <obligations> associated with the <effect> being returned by the given level of evaluation.  For example, a <policySet> may include some policies that return Permit and

other policies that return Deny for a given request evaluation. If the policy combiner returns a result of Permit, then only those obligations associated with the policies that returned Permit are returned to the next higher level of evaluation.  [If

the PDP's evaluation is viewed as a tree of policyCombinationStatements, policyStatements, and rules, each of which returns "Permit" or "Deny", then the set of <obligations> returned by the PDP will include only the obligations associated paths where the effect at each level of evaluation is the same as the effect being returned by the PDP.]

 

If the PEP does not understand an obligation, it should deny access. The PDP just collects obligations.

 

policyStatement and policyCombinationStatement allow determinism:

their "combiner"s can control order or completeness of evaluation.  If determinism is desired at the expense of performance, then the combiner algorithms can force evaluation of all rules and policies.

 

XACML will not define "profiles" for specific application domains such as J2SE.  XACML will try to anticipate issues that may arise in using XACML within various domains, and may give examples of how those issues can be resolved using XACML.

 

DEFERRED ISSUES AND QUESTIONS:

 

This is a list of issues and topics that came up, but that we deferred.  Some of these may have been effectively closed, but I am erring on the side of caution in listing possible open issues here.

 

[Sekhar]PDP-oriented versus Policy Writer oriented?  Wants to  keep all rules from one policy writer as a discrete collection.  What do you call this thing?

 

Exchanging <rule>s: is this valid XACML?

 

[Carlisle]Does PRP/PDP have a base policy?  Does PDP publish its  base policy?

 

[Anne/Sekhar]See a need to allow a PEP to provide a Base policy to the PDP as part of or in conjunction with the authorizationDecisionQuery.

 

[Tim]Special case for hierarchical subjects and resources to make merging targets simpler.  Or is higher-level target just the union of lower level targets?  Anne: but doesn't this only apply when the meta-policy uses "closest match"?

 

[Anne]Is higher-level target derived or declared?  If derived, by whom?  On what trigger?  At time a new <rule> or <policyStatement> is added to a list?

 

Which <rule> combiners will we spell out?

 

[Carlisle]Extensibility points.  Is <rule><effect> extensible?

 If additional values, then have to define a new <rule> combiner that references them?

 

[Simon] syntax for referring to resource in SAML authorizationDecisionQuery.  This is a SAML and XACML syntax issue: they have to be coordinated.

 

How do we know whether an attribute is of subject, resource, etc.?

 

How is obligation returned to PEP?  SAML changes required.

[Hal] Is a SAML response that has advices and conditions the right way to return obligations.

 

[Konstantin] can same PDP, with different extension profiles, handle J2EE, J2SE, .NET, etc.?

 

[Anne] Does Predicate in referencing an attribute need the attribute authority name, authority key, ClassName, class base location?

 

[Hal] Need to have way to restrict XACML to subsets so that a given PDP/PRP can handle.  E.g. PDP might be "J2SE-compliant".

 E.g. [blue sky] limit on numbers of rules, only certain combiners supported, limits on # of levels of policyCombiners, only certain ways to reference a policy inside a policyCombinationStatement, only those things required to support J2SE.  Spell out to a PAP how it is limited to apply to a given PDP.  PDP spells out what it can support.

 

[Konstatin] wants more verbal text around element types.  Have UML as well as XML.  Purpose is to sell ideas behind XACML to someone who does not understand XML.

 

Are obligations mandatory to implement for XACML compliance?

 

DETAILED NOTES:

 

These are my sequential notes.  I have made some of the terminology a bit more consistent with our final agreements, but in general, information is presented here as it evolved. Syntax often represents intermediate discussion proposals, and should not be confused with the AGREEMENTS REACHED above.

 

Agenda:

 

Monday, March 11

 

9:00 a.m. - 5:00 p.m. (or later):

   - aside from roll call, etc., for the first 10 minutes or so, we take as much of the day as necessary to come to consensus on the definition and high-level contents of

         RULE,

         ("basic" or "elementary") POLICY,

         ("compound" or "higher-level") POLICY, and

         META-POLICY

   - breaks:  roughly 10:30-10:45;  12:00-1:00; 3:00-3:30

   - be prepared to camp out in the Sun conference room if

     necessary.  I would really like these basic definitions to

     be closed before we adjourn on Monday.

 

Tuesday, March 12th

 

9:00-10:30:    Post-conditions / Obligations discussion (led by Michiharu)

10:30-10:45:  BREAK

10:45-11:15:  Post-conditions / Obligations discussion

11:15-12:00:  Arithmetic Operators discussion (led by Ernesto or Tim)

12:00-1:00:    LUNCH

1:00-2:00:      Extensibility discussion (led by Simon)

2:00-3:00:      Use Case discussion (Michiharu on protecting XML resources; Sekhar or Simon on J2SE; any others?)

3:00-3:30:      BREAK

3:30-5:00:      Resolve as many remaining issues from the Issues List as practical

5:00:              Adjourn

March 11, 2002

 

Agenda:

o Resolve Rule, Policy, MetaPolicy

o

 

RULE/POLICY/METAPOLICY

 

Simon: Presented following model:

 

 r1: g+(view, /dir1/file1.html, user1) if a>b and c>d.

 r2: g+(view, /dir1/file*, user1) if c>d.

 r3: r(view, /dir1/file1.html, user1) if e>f

 

 Request: g(view, /dir1/file1.html, user1)

 

 Can say have to solve restriction first, then positive rules.  Answer to request will be yes/no.

 

 Now say don't care about restrictions first, just match in order.  Will arrive at a yes/no.

 

 Now if have separate policies administered by different authorities.  Each can answer yes/no.  Need way to combine:

   solve P[A](P,R,A), P[B](P,R,A)

 Need another meta-policy: P[A] OR P[B]

                           P[A] AND P[B]

 Metapolicies for rules and policies are different.

 

 Can match query against rule and see which one applies. Simon suggests taking two rules, grouping into the policy, but don't try to make one rule out of the two.

 

Sekhar: "policy" versus "rule"

 

 Now PDP-oriented.  ebXML has Registry Client, Registry Server. Client wants to impose conditions on server access for business partners.  So client writes XACML policy.  Policy is submitted as part of the content.  Policy contains rule statements of some sort: resources to be protected, rule for each resource.

 What do you call the thing where set of rules is submitted by a policy writer.

 

 Wants to keep all rules from one policy writer as a discrete collection.  Wants to be able to send this collection as part of a SOAP request.  Simon: Target is union of all targets in

 rules.

 

Carlisle: PDP only evaluates policies, which are fully worked out rule statements or policy combination statements.  It doesn't make any sense to assign an effect to a rule unless you have a meta-policy.  Policy writer can override the meta-policy.  At

 rule level, effect is a hint.

 

Pierangela: Is meta-policy associated with policies or with rules?

 

Simon: same two rules may be used in different ways in two different policies.  Carlisle says this is same as no effect on the rule: the policy writer who includes the rules will determine the effect in this case.

 

Don: might want to include effect in the metapolicy without implying use of a specific metapolicy.

 

Polar: even policy writer does not know how his policy will be combined administratively.  Effect determines how evaluation gets mapped to the higher logic.

 

Hal: thinks <effect> is a hack.  It is when you have loosely coupled policy administrators that you really need metapolicy. Each needs to see how his piece fits into the whole world only enough to do his job.

 

Konstantin: only one person writes rules for one policy.

 

[Tim Moses came in here]

 

Anne: two models: database of rules that are sorted into a logical statement according to a metapolicy; high-level policy that refers to specific rules or sub-policies.

 

Why have metapolicy ref in rule?

 

Don: have we removed requirement for not wanting to have to retrieve all rules. [NO]

 

Simon: proposes only policy writers, no rule writers.

 

Hal: proposal "rule is atomic unit of administration".  Policy is combination of policies or rules.

 

Simon: merge vs. combine.  disagrees because no semantics.  Two cases: two policies from different sources to be combined (="policy combination"); take two policies, super-administrator will merge the two policies.  Super-administrator can choose to combine vs. to merge.  Rule=authorization to perform an action on a resource.  One target, one effect.  Polar says merge vs combine must be equivalent by Church-Rosser property.

 

Hal: still need finer grained targetting.

 

Assume for now that targets are defined: may be complex, may be simple.

 

Curently, metaPolicyRefs always point up: from rule or from policy.  ruleCombiners and policyCombiners now point down.

 

<rule>

  <target>

    <subject>..</subject>

    <action>..</action>

    <resource>..</resource>

  </target>

  <condition>

    P(S,A,R, ...)

  </condition>

  <effect>..</effect>     Permit, Deny

</rule>

 

<policy>

  <target>                optional.  For finding applicable policies when have multiple ones either in database or when will need to combine.

    <subject>..</subject>

    <action>..</action>

    <resource>..</resource>

  </target>

  <metaPolicyRef>..</metaPolicyRef>

  <rule>..</rule>

  <rule>..</rule>

</policy>

 

Given a particular request, PDP only acts on a policy that has all applicability elements resolved.  Rule-combination policy already applied or not?

 

Exchanging rules: is this valid XACML?  Role of targets in the policy.  PRP returns one completely applicable policy to PDP. PRP needs a base policy that applies to everything.  It returns a metaPolicyRef and set of rules.

 

Is XACML for policy writers (PAPs) or for PDP?

 

[LUNCH BREAK]

 

Meta-policy now associated with policy, not rule.  Meta-policy points down, not up now.  Meta-policy1 is a rule-combiner. Metapolicy2 is a real metapolicy (combining policies).

 

Pierangela gives 5 min.  How do you combine boolean policy with metapolicy.  Carlisle: you don't.  You deal with one or the other.

 

Pierangela: if multiple levels of composition, is one level the root?

 

Polar: role of PRP and how many levels of metapolicy?  Have to guarantee top level returns only one, or else have to have a way to combine them.

 

Carlisle: suggestion that PDP publishes its base policy.  Anne: case where PEP provides the base policy.

 

Simon: PDP should know which resources it is intended to protect.  Hal: PRP sits in front of huge database of policies and returns the applicable ones to the PDP.

 

Hal,Sekhar: policy is what policy writer writes.  Applicable policy is the set of policies that apply to a given request.

 

Set of applicable policies will be determined depending on matching the request against the target, and will be retrieved by the PRP.

 

Tim: special case for hierarchical subjects, resources.  Makes combining policies much simpler.  Anne: but doesn't this only apply when the meta-policy uses "closest match"?

 

Proposal: Policy target is derived from the targets in the rules.  Alternative is that policy target is Declarative, specified by policy writer as "intended target".  Consequences:

 

  Derived:

  - complex calculation

  - updated whenever a rule is added to database?

  - simplify target to make this feasible

  - derived subject is difficulty

  Declarative:

  - declare intention of use

  - target is broader than true applicability

  - lower policies and rules may not be consistent with each

    other.

  - can have rules that never fire.

  - Could write tools to analyze consistency.

 

PDP looks at target in its directly referenced policies, and selects based on that.

 

Note: target specification must enter in to the logic.  It is the first hurdle.  There may be more in the <condition>.

Pierangela: deriving targets much harder if conditions are included in applicability.  Tim suggests conditions are handled in the policy that includes the rules:

  <or>

    <and>

      <equals>

        <resource>

        <T1>

      </equals>

      <C1>

    </and>

  ...

  ...

  </or>

 

Polar:

  <rule>

    <target>

      <subject>

      <action>

      <resource>

      <additionalCriteria>

    </target>

    <condition>

    <effect>

  </rule>

 

  <policy>

    <target>

      <subject>

      <action>

      <resource>

      <additionalCriteria>

    </target>

    <ruleCombinerRef>

    <rule1>

    <rule2>

  </policy>

 

  <policyLevel2>

    <target>

     same

    <metaPolicy1>

    <policy1>

    <policy2>

  </policyLevel2>

 

Rule produces three results: grant, deny, inapplicable.

 

Conditions are always applicable from the rule writer's point of view.

 

Polar: OwnerOf(R,S) -> [R is "old", Permit]

        target          cond        effect

 <policy>

  <target>

    <resourceName>=Age is "old"

    <subject> any

  </target>

  <condition>

    OwnerOf(R,S)

  </condition>

  <effect>Permit</effect>

 </policy>

 

 If <condition> is false, then return <not applicable>.  By metaPolicyOne, this will result in <deny>?

 

 Need different rule-combiner from the "MetaPolicy One" to get the intended semantics.

 

Pierangela: Need way to indicate that someone gets permit without implying that everyone else gets deny.

 

semantics:

           condition

  target   T      F

  T        effect inapp

  F        inapp  inapp

 

Polar: then rule and policy same.  Move these semantics up to higher level.

 

Michiharu: specific use cases.  Simple example does not use <condition>.  More complex example uses conditions and meta-policy-hierarchy.  His example also implies complexity in the <target>, at least at the level of using subject role (attribute), but Michiharu says that can be moved out to <condition> in newer proposal.

 

Polar: so scope of rules does not go beyond the policy. Michiharu's <ruleSet> is equivalent to rule-combiner policy level.

 

Pierangela: what if not all information available?  Answer: indeterminate.  Error condition.  Rule-combiner handles this case. Rule combiner can specify algorithm in plain English referenced via a URI.

 

Now don't need permitOnlyIf because now have Deny and way for <rule> combiner to give "permitOnlyIf" semantics to <not>Deny if that is what is desired.

 

Issues:

- Do we need more than one RuleCombiner

- Syntax for specifying RuleCombiner (URI; can be English text)

- Effect extensible or just Permit/Deny?

  Resolution: if additional values, then have to define a new RuleCombiner that references them.

 

<rule> = v10 minus metapolicyref; effect={permit,deny}; target and condition equally participate in applicability.  Effect returned only if both are true.

 

<rule> Truth Table:

  Target  Condition  Effect

  ------  ---------  ------------

  T       T          [Effect]

  T       F          Inapplicable

  T       Indet.     Indet.

  F       T          Inapplicable

  F       F          Inapplicable

  F       Indet.     Inapplicable

 

[AFTERNOON BREAK]

 

POLICY: generated and manipulated by one person in one place.

 

  <policy>

    <target>

    <ruleSet>

  </policy>

 

Fits into data model in case where you want to write a policy down.  Could pass policy back to a PDP, in which case the target is then superfluous.

 

<ruleSet xsi:".....">

  <ruleCombinerRef>

  <rule>...</rule>   Can contain rule syntax or ruleId.

  <rule>...</rule>

</ruleSet>

 

Need for ruleSet depends on whether ruleCombiner is associated with ruleSet or whether ruleSet is re-usable with other rules.

 

Signature on policy <rule>: can also include hash of <rule>, or just (hash of?) <RuleId>.  If hash of <rule> syntax, then policy writer wants this particular <rule> content.  If just (hash of?) <ruleId>, then policy writer wants current rule associated with this ruleId.  Example: a <ruleId> may be associated with semantic "conditions under which someone is allowed to access Anne's files".  Anne may change the specific conditions over time, but might retain the same <ruleId> so that the current rule can be referenced in a policy without having to rewrite the policy.

 

  <ruleRef uri="http://..."

           authority="..."

           hash="..." (optional)

  </ruleRef>

 

Policy is smallest unit that can be signed.  Rules can stand by themselves, but can't be signed.

 

v10 has <rules>.  Take metaPolicyRef (ruleCombiner) out of <policy> and  put into <rules> and then <rules> is like new <ruleSet>.

 

Policy extends saml assertion:

  <MajorVersion>

  <MinorVersion>

  <IssuerInstant>

  <Issuer>

  <AssertionId>

 

<policyStatement>

  <target>

  <ruleSet combiner="...">

    <rule> [ruleId (attribute of rule element)

         or rule syntax] </rule>

    ...

  <ruleSet>

</policyStatement>

 

  Target   RuleSet   Result

  ------   -------   --------

  match    [effect]  [effect]

  match    Inappl.   Inappl.

  match    Indet.    Indet.

  no-match           Inappl.

 

Carlisle: is policyStatement always wrapped in a SAML assertion. If you want to select policies based on data other than <target> and <ruleSet>, then you have to embed policyStatement in SAML assertion.

 

Michiharu: what if you want to assign priorities to rules.

Proposal: evaluate in sequence order.  Define new ruleCombiner that understands priority attribute in rules.

 

Now:

  <ruleX>

    <rule>

    </rule>

    <ruleMetaData

        name="..." value="..." />

    <effect>   CHOICE

        Permit   or   Deny

    </effect>

  </ruleX>

 

RuleCombiner can operate on ruleMetaData, which might include something like priority.

 

<policyCombinationStatement>

  <target>

  </target>

  <policySet combiner="...">

    <policyDesignator attributes=<policyMetaData> >

      <choice>

        <policyRef>

        <policyStatement>

        <policyCombinationRef>

        <policyCombinationStatement>

        <saml:assertion>

            <policyRef>

            <policyStatement>

            <policyCombinationRef>

            <policyCombinationStatement>

        </saml:assertion>

      </choice>

      <policyMetaData />

    </policyDesignator>

  <policySet>

</policyCombinationStatement>

 

Version1: only use <policyStatement> and <ruleStatement>?

Alternative: flesh out, but then remove in a month if we don't like it.

Consensus: we need to be able to combine policies.

 

Version1: only use <policyRef> or <policyCombinationRef>?

 

Consensus: leave it all in for now.

 

Simon: what does the policy "combiner" mean?

 

Polar:

  Example: evaluate first policy in list that gives a determinate answer.

  Don't want to specify syntax for saying how to say "trust policies from IssuerA" at this point.

 

[6PM  ADJOURN]

------------------------------------------------------------------------------------------------------------

March 12, 2002 (Day 2)

 

OBLIGATIONS

 

Obligation specified via URI and value attribute.

 

 <policyStatement>

   <target>

     <subjects>

     <resources>

     <actions>

   </target>

   <ruleset>...</reuleset>

   <obligation>

     <onPermit>

       <operation uri="http://www.xyz.com/obligation/log"

            value="abc" />

       </onPermit>

   </obligation>

 </policyStatement>

 

RuleCombinationStatement and PolicyCombinationStatement allow determinism: can control order or completeness of evaluation.

 

Michiharu: Post-Condition

-Term: provisional action, obligation, provision; consensus:

            obligation

 

-Obligation can be associated with deny, not just permit

-Specified using URI.  One parameter: value attribute

 

 <policyStatement>

   <target>

     <subjects>

     <resources>

     <actions>

   </target>

   <ruleset>...</reuleset>

   <obligation>

     <onPermit>

       <operation uri="http://www.xyz.com/obligation/log"

            value="abc" />

       </onPermit>

   </obligation>

 </policyStatement>

 

-More complicated if specify postconditions at rule level.

 

-RuleCombinationStatement and PolicyCombinationStatement allow determinism: can control order or completeness of evaluation.

 

Issue: how is obligation returned to PEP.  SAML changes required.

 

Issue: can get higher level result that is opposite of a lower-level result.  Need to keep list of obligations associated with "deny" and list associated with "permit" intermediate results.  Based on ultimate decision of "permit" or "deny", the set of obligations associated with that result is returned.

 Example:

 If user="Anne" deny

 OnDeny: obligation="log"

 Assume: user is not "Anne".  Above does not return anything.

 

Combiners example: All-Must-Permit

     Must evaluate *all* policies regardless

 If all rules evaluate to Permit, gather all their obligations for Permit, but if one rule emits an Indeterminate or a Deny, only the Deny obligations are gathered.

 

If PEP does not understand an obligation, it should deny access. PDP just collects obligations.

 

Simon: define <obligation> element which can be in rule or in policy.  e.g. type of rule <onGrant><targets><obligation>. General objection: too complex.  Wants to have obligations associated with effects AND target.

 

Issue: have obligations on rules or not? 

 

Konstantin: Example from Pierangela's paper: Particular resources may have access by employees or by outsiders who sign an agreement.  Obligation may be "sign an agreement" if the "access by outsiders" fires.

 

Polar:

  <rule: effect with obligations

  <policy  <ruleSet: combiner to combine effects and their obligations

      Can also have at policy level: onPermit, onDeny

  <policyCombination <policySet: combiner wo combine effects and policy with its obligations

 

Two points of view: whether to retain list of obligations from the lower level evaluation when higher levels return a different result.  Everything returns Permit with both Permit and Deny obligations or Deny with both Permit and Deny obligations.

 

No matter what combiner is used: must return complete lists?

 

Tim: allow obligation <onFire> of a rule.  Possibly as attribute.

 

Issue: are obligations support mandatory or not.

 

Simon: could define "standard evaluation context".  Combiners must populate "standard evaluation context" in certain ways, such as retaining onPermit and onDeny

 

Agreement: the only obligations carried up are those that fit the effect at a higher level.  Makes sense to allow obligations at the rule level.  At rule level: just <obligation>.  At

 ruleSet level, <onPermit or <onDeny and <obligation>.

 

  <policyStatement>

    <target>

      <subjects>

      <resources>

      <actions>

    </target>

    <ruleSet Combiner="myURI">

      <ruleDesignator>

        <ruleMetadata>

        <ruleReference> or <ruleInstance>

      </ruleDesignator>

      <ruleDesignator>...</ruleDesignator>

      <obligations>

        <onPermit>

          <obligation uri="myobligation1" value="abc"/>

          <obligation uri="myobligation2" value="cde"/>

        </onPermit>

        <onDeny>

          <obligation>

        </onDeny>

      </obligations>

    </ruleSet>

  </policyStatement>

 

The obligation result is propagated to the next higher level only if the higher level's combiner results in an effect that matches the <on[Effect]> obligations.  E.g. RuleSet may evaluate to Deny.  <onDeny> associates actions A and B with that result. PolicyCombiner that uses this Policy may return <permit>, and these obligations will be lost. Only the obligations that are associated with the resultant effect are propagated to the upper policy evaluation.  In the case of Error, NotApplicable, Indeterminate, no obligations are propagated.

 Agreement: omit obligation from rule (later changed).

 

Konstatin: sceptical about obligations in general.

 

[MORNING BREAK]

 

  <policyCombinationStatement>

    <target>

      <subjects>

      <resources>

      <actions>

    </target>

    <policySet Combiner="myURI">

      <policyDesignator>

        <policyRef> or <policyStatement> or

          <policyCombinationRef> or <policyCombinationStatement> or

          <saml:assertion>

        <policyMetadata>

      </policyDesignator>

      <policyDesignator>...</policyDesignator>

      <obligations>   OPTIONAL

        <onPermit>

          <obligation uri="myobligation1" value="abc"/>

          <obligation uri="myobligation2" value="cde"/>

        </onPermit>

        <onDeny>

          <obligation>

        </onDeny>

      </obligations>

    </policySet>

  </policyStatement>

 

ARITHMETIC OPERATORS - presentation by Tim

 

MathML

-Two aspects

 -Presentation (we don't care about)

 -Expression   (how to specify a mathematical statement)

 

-Example:

 <!-- calculate 27-x -->

 <apply>

   <minus/>

   <cn>27</cn>  <!-- cn can contain number -->

   <ci>x</ci>   <!-- ci can contain variable -->

 </minus>

 

-Variable must be declared (other syntax).

 

-Motivation for wanting at least some arithmetic operators in XACML: Assume designated effect should operate only if subject's age is greater than or equal to 18.  Currently have to update rule each day.

 

-In XACML

 <not><lessOrEqual>

   <apply>

     <minus/>

       <saml:AttributeDesignator AttributeName="today'sDate"

         AttributeNamespace="//medico.com/" />

       <saml:AttributeDesignator AttributeName="patientDoB"

         AttributeNamespace="//medico.com/record/patient/"/>

     </apply>  

     <saml:Attribute AttributeName="ageOfConsent"

       AttributeNamespace="//medico.com">

       <saml:AttributeValue>

         <ageOfConsent xsi:type="date">16-0-0</ageOfConsent>

       </saml:AttributeValue>

     </saml:AttributeValue>

   </saml:Attribute>

 </greaterOrEqual></not>

 

-Result of <minus> is an xsi:date

 

DEFERRED DISCUSSION: how do we know whether an attribute is of subject, resource, etc.?

 

-We could eliminate <apply> and use <plus>, <minus>, <times>, <divide> directly at higher level.

 

-Hal: real-world date arithmetic is incredibly complex.

 

-Issue: does XACML enforce type safety, or does PDP do it?  Error can be returned.  We need to specify what is allowed, or point to somewhere else. (ACTION: Polar says there is an RFC specifying type conversions).

 

-Michiharu: in IBM's early XACML implementation, they chose a general syntax for predicate and functions.  User provides functions.  Specify types.

 

 <predicate name="compareDate">

   <parameter value="after" />

   <parameter>

     <function name="getDate" />

   </parameter>

   <parameter>

     <function name="getValue">

       <parameter value="./period/start_time" />

     </function>

   </parameter>

 </predicate>

 

-Some predicates and functions are pre-defined.  Can also construct functions via extensions.  Defined in a different schema.

 

-Tim: this requires defining a different function for each type.

 

-Deadline: two weeks from yesterday.  March 25, 2002.  Present at the subcommittee meeting.

 

-Policy Model subcommittee is ready to disband.  Now subcommittee time slot and task will be XML Schema.

 

-Michiharu: use MathML-based syntax or not?  E.g. are ci and cn elements extensible or not.  How are types associated with parameters.

 

-Ernesto flying home from Spain tomorrow.

 

[LUNCH BREAK]

 

[Simon] syntax for referring to resource in SAML authorizationDecisionQuery.  This is a SAML and XACML syntax issue: they have to be coordinated.

 

Consensus: referring to SAML attributes is not a model issue.

 

EXTENSIBILITY - presentation by Simon

 

-Core schema is a good interchange format.

 

-Extensibility point: predicate

  e.g. J2SE permission class must be signed by a specific issuer. Define special predicates.  Publish schema for that. Possibly enough syntax in core schema to handle this.

-XACML syntax is not user-friendly.

  e.g. J2SE composite subject hard to express in core schema.

 

-Create a non-normative schema.  Triplet-based.  Lots of extension points.  Profile in non-normative way for various applications or requirements.

  E.G. non-normative profile for J2SE, ebXML, etc.

 

-Don't depend on J2SE to profile their own because they would go through the same pain.  They would need to understand XACML schema, etc.  Like providing a guidebook.

 

*Konstantin: can same PDP, with different extension profiles, handle J2EE, J2SE, .NET, etc.?

 

-Conversion from extension profile to normative schema is well-defined [according to Simon].

 

[Anne,Sekhar] Would rather have a policy composition tool that accepts syntax like what I am familiar with and outputs a standard XACML instance.

 

EXTENSIBILITY - presentation by Sekhar

 

Sekhar: alternative way to extend: J2SE, etc. define their own schema.  Define attributes pertinent to the J2SE platform. These plug into the standard XACML.  J2SE extension would just explain the attributes and the predicates.

 

-Extensibility schema:

 xacmle:RuleCategoryType

    e.g. grant, deny, restriction

 xacmle:BasicRuleType

    RuleHead

      Subject: abstract, extension point

      Resource: abstract, extension point

      Actions: abstract, extension point

    Constraints: abstract, extension point

 

-Translated into core XACML.  Gives framework for writing application-specific schemas.

 

-Model extensibility only at Predicates:

 substitutionGroup=xacml:Predicate

 e.g. SignatureVerifyFunction

      SignatureVerifyFunctionType

        name="ClassName" type="anyURI"

        ref="ds:KeyInfo"

 

-Does Predicate need attribute for authority name, authority key, ClassName, class base location?

 

-Predicate Must return true or false.

 

-Predicate can have no side-effects.

 

[Hal] Is a SAML response that has advices and conditions the right way to return obligations?

 

[Hal] Need to have way to restrict XACML to subsets so that a given PDP/PRP can handle it.  E.g. PDP might be J2SE-compliant. E.g. [blue sky] limit on numbers of rules, only certain combiners supported, limits on # of levels of policyCombiners, only certain ways to reference a policy inside a policyCombinationStatement, only those things required to support J2SE.  Spell out to a PAP how it is limited to apply to a given PDP.  PDP spells out what it can support.

 

Sekhar: J2SE can be handled via core syntax

 

<xacml:ruleStatement>

  <xacml:target>

  . <xacml:subjects>

  . . <saml:Attribute AttributeNameSpace="//java.sun.com-URI"

                      AttributeName="principal"

  . . . <saml:AtributeValue>

  . . . . <saml:NameIdentifier

            SecurityDomain="javax.security.auth.x500.X500Principal"

            Name          = "cn=Alice"/>

  . . . </saml:AttributeValue> 

  . . </saml:Attribute>

  . </saml:subjects>

  . <xacml:resources>

  . . <saml:Attribute ...

  . .                AttributeName="permission"

  . . . <saml:AttributeValue

  . . . . <xs:string>java.io.FilePermission</xs:string>

  . . . </saml:AttributeValue>

  . . . <saml:AttributeValue>

  . . . . <xs:string>/home/Alice</xs:string>

  . . . </saml:AttributeValue>

  . . </saml:Attribute>

  . </xacml:resources>

  . <xacml:actions>

  . . <saml:Action>Read</saml:Action>

  . . <saml:Action>write</saml:Action>

  . </xacml:actions>

  </xacml:target>

</xacml:ruleStatement>

 

[BILL LEFT AROUND HERE]

 

Another way:

 

<xs:schema targetNamespace="JavanamespaceURI:>

. <complexType name="principal">

. . <xs:complexType

...

</xs:schema>

 

-Allows use of domain-specific names like j2se:principal.

 

-Provides the #ANY schema for attributes within a given domain.

 

-PDP for this would need to be J2SE-aware.

 

-This profile would need to be defined via JCP.

 

-[Hal] Subject----->Permissions--->specific Permission

       Signer--^

       ToD-----^

 Use XACML to decide which Permissions you get, not what

 

-[Anne] See how much we can do with predicate extensions.  Rough

 example:

 

grant "cn=Anne" {

   FilePermission "/home/aha" "read,write"

}

 

<rule>

 <target>

  <subject>"cn=Anne"</subject>

  <resource>"java.io.FilePermission"</resource>

  <actions>

    <action>"read"</action>

    <action>"write"</action>

  </actions>

 </target>

 <condition>

   <implies>

       <attributeValue>

         class:java.io.FilePermission

           "/home/aha" "read,write"

       </attributeValue>

       <attributeRef>

         <saml:attribute>[RequestedPermission]</saml:attribute>

       </attributeRef>

   </implies>

  <effect>Permit</effect>

</rule>

 

AFTERNOON BREAK

 

PROTECTING XML RESOURCES - use case presented by Michiharu

 

-Extends extension pointS "predicate" and "function"

 

USING XPATH EXPRESSION

 

Example:

 

  Predicate: XPathMatch(arg1,arg2,arg3)

  Return:    Boolean

  arg1:      String (URI)

  arg2:      String (XPath)

  arg3:      String (Xpath)

  e.g. XPathMatch("medico.com/patient-123.xml",

                  "/record/patient/patientDob", "//*")

       -> true

 

Example:

 

  Function:   resourceSelector(returnType)

  Return:     String

  returnType: ["uri","path","xpath",or "all"]

  e.g. resourceSelector("//medico.com/patient-123.xml

                        #xpointer(/record/patient/patientDoB)")

       -> /record/patient/patientDoB

 

-Resource Extension:

 can compress many lines from the example to go into one element and it can be re-used

 

USING PATH EXPRESSION

 

-e.g. function: resourceSelector("//medico.com/patient-123.xml

                       ?/record/patient/patientDoB")

      -> /record/patient/patientDoB

 

-e.g. predicate: pathMatch(arg1,arg2)

      return: Boolean

      arg1:   String(Path)

      arg2:   String(Path)

  matchPath("/record/patient/patientDoB", "*/email")

    -> false

 

-Resource Extension:

  <resources>

    <resourcePathMatch value="*/email"/>

    <resourcePathMatch value="*/phone"/>

  </resources>

 taken from:

  <resources>

    <or>

      <predicate name="pathMatch">

        <function name="resourceSelector">

          <parameter value="path"/>

        </function>

        <parameter value="*/email"/>

      </predicate>

      <predicate name="pathMatch">

        <function name="resourceSelector">

          <parameter value="path"/>

        </function>

        <parameter value="*/phone"/>

      </predicate>

    </or>

  </resources>

 

[Tim]may be possible to use just the above regular expression match  (e.g. <resourcePathMatch value="*/email"/>)

 

[Hal]Instead of providing an instance document, perhaps specify schema: policy applies to any document conforming to the schema.

 

[Hal]Might want to specify via DTD.

 

[Anne]Michiharu's <resources> element test would need to be in the <condition>, since might not be able to find a given value.

 

Make the target matching algorithm a URI.  We specify regular-expression match.  Possible to define and specify others.

 

Michiharu can live with less generality than XPath, but his first motivation was to use XPath.

 

Resources can be internally structured via a schema.  Then the regular expression match operates on the pointer into the resource.

 

[Hal]Could define resource as a sequence of strings.  Define regular expression for each substring.  This has been sufficient for their purposes.

 

[Hal]Need to specify class of documents to which target can apply.  Either instance or schema or ....

 

Go back to one target matching algorithm, but add way to say target resource must conform to a specific schema or is in a namespace.  Need to define effect when applied to an unstructured resource.

 

[Michiharu]Assumes <policy> restricts the application to particular target document namespaces, schemas.

 

[Anne]For unstructured document resource, target must be URI (or regular expression matching URI).  For XML document, target can be URI plus optional XPath or Path expression.

 

[POLAR LEFT HERE]

 

*Konstatin wants more verbal text around element types.  Have UML as well as XML.  Purpose is to sell ideas behind XACML to someone who does not understand XML.  @Hal and @Konstantin willing to work on this after Version 11 available.  "Primer"

 document.

-ruleCombiner*, policyCombiner*, instead of ruleCombinator, policyCombinator

 

Next F2F

-Dates: weeks April 15, April 22, April 29

  -Michiharu: week of April 22nd best, May 6 second, not

   avail. week of April 29

  -Sekhar: not avail. weeks of April 15 or April 22

-Place: Milan, Bay Area (Ken), Manhattan Beach (Bill), Burlington

  -Pierangela, Ernesto in Milan first choice: get representative

   hotel prices

  -Ken Yagen, CrossLogix, Bay Area: if no extra room cost

  -Bill Parducci, LA: if no extra room cost

 



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


Powered by eList eXpress LLC