Re: [xacml] Issue#12: Obligations: Chronicle Attribute

[Erik Rissanen <erik@axiomatics.com>]

I like also think this is a good use case and we should incorporate it.

My initial reaction was that the chronicle could be seen as part of the
obligation id, but after some thinking (and an off list response from
David) I think it should be its own separate attribute. Having it part
of the obligation id means triplicating obligation ids and (as Anne
pointed out to me off list) separating this attribute enables a more
modular PEP implementation, where a core PEP is unaware of the
obligation semantics, but does scheduling, and at the appropriate time
passes on the obligations to separate modules for enforcement.

If I consider this in the context of the recent obligation family work,
I am still unsure whether the chronicle should be an attribute of the
obligation, rather than the obligation family. If we would implement
obligation families, the same effect could be achieved through
attributes of families, rather than the obligations themselves.

The argument for having the chronicle part of the family is that the
chronicle attribute may be in conflict with attributes of a family. I
see family types as means of collecting consistent attributes of
obligations. Conflicting attributes go into separate family types. If we
put the chronicle attribute into the obligation itself, it will
effectively end up in all families, and potentially conflict with
another attribute somewhere.

For instance, the sequential family specifies an order of obligations
enforcement. This order could be in conflict with the order implied by
the chronicle attributes. Well, in this case it is simple to resolve by
just saying that the chronicle has priority, but could there be some
more difficult problem?

Overall I think I am leaning towards putting the chronicle into the
obligation, not the family, but I will think more about this.

Regards,
Erik


Anne Anderson wrote:
> We have received a proposal to add timing of obligation fulfilment as
> a use case for our generalized Obligations work. I think this use case
> is well-supported and should be incorporated into our work. I am
> forwarding the proposal for those of you not on xacml-users.
>
> Regards,
> Anne
>
> ------------------------------------------------------------------------
>
> Subject:
> [xacml-users] Chronicle Attribute
> From:
> David Chadwick <d.w.chadwick@kent.ac.uk>
> Date:
> Fri, 25 May 2007 18:23:56 +0100
> To:
> xacml-users@lists.oasis-open.org
>
> To:
> xacml-users@lists.oasis-open.org
>
> Return-path:
> <xacml-users-return-31-Anne.Anderson=Sun.com@lists.oasis-open.org>
> Received:
> from sml-sfvt2a.sfvic.sunlabs.com ([152.70.2.220]) by
> mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1
> HotFix 0.02 (built Aug 25 2004)) with ESMTP id
> <0JIL0089LXOSCC50@mail-srv.sfvic.sunlabs.com> for
> aa74233@sml-sfvic-mail-swan.SFBay.Sun.COM; Fri, 25 May 2007 10:24:28
> -0700 (PDT)
> Received:
> from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by
> mail-swan.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1
> HotFix 0.02 (built Aug 25 2004)) with ESMTP id
> <0JIL004S0XOSQ500@mail-swan.sfvic.sunlabs.com> for
> aa74233@sml-sfvic-mail-swan.SFBay.Sun.COM (ORCPT
> Anne.Anderson@Sun.com); Fri, 25 May 2007 10:24:28 -0700 (PDT)
> Received:
> from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM
> [129.146.11.52]) by sfbaymail2sca.sfbay.sun.com
> (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4PHORGP001647 for
> <anne.anderson@sfbay.sun.com>; Fri, 25 May 2007 10:24:27 -0700 (PDT)
> Received:
> from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM
> [129.147.4.11]) by sunmail3mpk.sfbay.sun.com
> (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4PHOQuJ015431 for
> <@newsunmail1brm.central.sun.com:Anne.Anderson@sun.com>; Fri, 25 May
> 2007 10:24:27 -0700 (PDT)
> Received:
> from pmxchannel-daemon.brm-avmta-1.central.sun.com by
> brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04
> (built Jul 15 2005)) id <0JIL00F07XOQX100@brm-avmta-1.central.sun.com>
> for Anne.Anderson@sun.com (ORCPT Anne.Anderson@Sun.com); Fri, 25 May
> 2007 11:24:26 -0600 (MDT)
> Received:
> from sca-ea-mail-1.sun.com ([192.18.43.24]) by
> brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04
> (built Jul 15 2005)) with ESMTP id
> <0JIL00GSJXOHDAA0@brm-avmta-1.central.sun.com> for
> Anne.Anderson@sun.com (ORCPT Anne.Anderson@Sun.com); Fri, 25 May 2007
> 11:24:24 -0600 (MDT)
> Received:
> from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged))
> by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id
> l4PHNObJ007201 for <Anne.Anderson@Sun.com>; Fri, 25 May 2007 17:24:17
> +0000 (GMT)
> Received:
> from mms04es.sun.com ([150.143.104.74] [150.143.104.74]) by
> relay2.sun.com with ESMTP id BT-MMP-1808678 for Anne.Anderson@Sun.com;
> Fri, 25 May 2007 17:24:10 +0000 (Z)
> Received:
> from relay3.sun.com (relay3.sun.com [150.143.103.54]) by
> mms04es.sun.com with ESMTP id BT-MMP-1672341 for
> Anne.Anderson@Sun.com; Fri, 25 May 2007 17:24:10 +0000 (Z)
> Received:
> from relay41i.sun.com ([192.5.209.70] [192.5.209.70]) by
> relay3.sun.com with ESMTP id BT-MMP-1280720 for Anne.Anderson@Sun.com;
> Fri, 25 May 2007 17:24:10 +0000 (Z)
> Received:
> from ms01.oasis-open.org ([66.151.234.62] [66.151.234.62]) by
> relay4i.sun.com with ESMTP id BT-MMP-745007 for Anne.Anderson@Sun.com;
> Fri, 25 May 2007 17:24:10 +0000 (Z)
> Received:
> from [10.0.0.2] (helo=mail.oasis-open.org) by ms01.oasis-open.org with
> esmtp id 1HrdWL-0006CE-MA for Anne.Anderson@Sun.com; Fri, 25 May 2007
> 13:24:09 -0400
> Received:
> (qmail 2812 invoked by uid 508); Fri, 25 May 2007 17:24:06 +0000
> Received:
> (qmail 2804 invoked by uid 0); Fri, 25 May 2007 17:24:06 +0000
> Sender:
> xacml-users-return-31-Anne.Anderson=Sun.com@lists.oasis-open.org
> Message-ID:
> <46571BAC.8090702@kent.ac.uk>
> Organization:
> University of Kent
> MIME-Version:
> 1.0
> Content-type:
> text/plain; charset=windows-1252; format=flowed
> Content-transfer-encoding:
> QUOTED-PRINTABLE
> Precedence:
> bulk
> Delivered-to:
> mailing list xacml-users@lists.oasis-open.org
> Mailing-List:
> contact xacml-users-help@lists.oasis-open.org; run by ezmlm
> X-PMX-Version:
> 5.2.0.264296
> X-UKC-Mail-System:
> No virus detected
> X-UKC-MailScanner-From:
> d.w.chadwick@kent.ac.uk
> X-Virus-Scanned:
> by amavisd-new-20030616-p10 at oasis-open.org
> List-Post:
> <mailto:xacml-users@lists.oasis-open.org>
> List-Subscribe:
> <mailto:xacml-users-subscribe@lists.oasis-open.org>
> List-Unsubscribe:
> <mailto:xacml-users-unsubscribe@lists.oasis-open.org>
> List-Help:
> <mailto:xacml-users-help@lists.oasis-open.org>
> User-Agent:
> Thunderbird 1.5.0.10 (Windows/20070221)
> Original-recipient:
> rfc822;Anne.Anderson@Sun.com
> X-Spam-Status:
> No, hits=-2.6 tagged_above=-10.0 required=3.0 tests=BAYES_00
>
>
> Dear List
>
> in our recent research with Grid coordinated access control decision
> making, we used obligations to update a coordination database to
> record details of a users actions. The coordination database performs
> the same function as the retained ADI in ISO 10181-3. In this way we
> can implement applications such as ATM machine cash withdrawals over a
> distributed network using multiple stateless PDPs (such as the XACML
> PPD), and ensure that a user does not withdraw more than X amount per
> day from whichever machine he goes to.
>
> We have presented two papers about this, at Policy 2006 and MGC 2006.
>
> David W Chadwick, Linying Su, Oleksandr Otenko, Romain Laborde.
> “Coordination between Distributed PDPs”. Proc of 7th IEEE
> International Workshop on Policies for Distributed Systems and
> Networks, London, Ontario, 5-7June 2006 pp163-172.
>
> David W Chadwick, Linying Su, Romaine Laborde. “Providing Secure
> Coordinated Access to Grid Services”. Proceedings of 4th International
> Workshop on Middleware for Grid Computing - MGC 2006, In conjunction
> with ACM/IFIP/USENIX 7th International Middleware Conference 2006,
> Melbourne, Australia - November 27, 2006
>
>
> The net result is that we need a new attribute adding to the
> obligation element in XACML. The purpose of this attribute is a
> directive to the PEP to tell it WHEN to carry out the obligation:
> either Before, With, or After enforcing the user's access request. In
> most grid applications With is not appropriate since grid jobs can run
> for hours or days. So Before or After are often the most appropriate
> for grids (e.g when to send an email notification? before the job
> starts or after it finishes). We have implemented a Before option in
> GT4 with a coordination PDP that talks to an XACML PDP (more details
> of this in the MGC paper).
>
> Here is the new schema for obligation that we propose
>
> > xs:element name="Obligation" type="xacml:ObligationType"/>
> > <xs:complexType name="ObligationType">
> > <xs:sequence>
> > <xs:element ref="xacml:AttributeAssignment" minOccurs=”0”
> > maxOccurs="unbounded"/>
> > </xs:sequence>
> > <xs:attribute name="ObligationId" type="xs:anyURI" use="required"/>
> > <xs:attribute name="FulfillOn" type="xacml:EffectType" use="required"/>
> > <xs:attribute name="Chronicle" type="xacml:ChronicleType"
> use="optional"/>
> > </xs:complexType>
>
> The Chronicle simple type is defined as:
>
> >
> > <xs:simpleType name="ChronicleType">
> > <xs:restriction base="xs:string">
> > <xs:enumeration value="Before"/>
> > <xs:enumeration value="With"/>
> > <xs:enumeration value="After"/>
> > </xs:restriction>
> > </xs:simpleType>
>
>
>
> regards
>
> David