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] 7.7 Obligations


Title: RE: [xacml] 7.7 Obligations

I also agree.

> -----Original Message-----
> From: Anne Anderson - Sun Microsystems [mailto:Anne.Anderson@Sun.COM]
> Sent: Wednesday, October 09, 2002 9:05 AM
> To: Michiharu Kudoh; 'XACML TC '
> Subject: RE: [xacml] 7.7 Obligations
>
>
> I agree with Michiharu.  To restate:
> 1) Return a set of obligations with the understanding that
>    the PEP is expected to DENY access if it does not
> understand any one of
>    the obligations.  This is better than the PEP trying to
> tell the PDP
>    ahead of time which obligations it does understand.  The
> "deny if not
>    understood" method has been working fine for PKIX critical
> extensions.
> 2) Obligations associated with an authorization decision of DENY are
>    perfectly reasonable.  For example, "DENY" access and log
> the fact that
>    this user tried to gain access.
>
> "Michiharu Kudoh" <KUDO@jp.ibm.com> wrote:
> >Date: Wed, 09 Oct 2002 20:24:14 +0900
> >Based on the discussion on the list,
> >- Bill and I are in agreement.
> >- Daniel seems to be uncomfortable with an authorization
> decision like DENY
> >with obligation(s).
> >- Polar seems suggesting to include understandable obligations in the
> >request context to avoid emitting no-understandable
> obligations to PEP from
> >PDP.
> >
> >My opinion is that DENY with obligation (e.g. deny provided
> access must be
> >logged) is still useful for some applications e.g. security
> policy for a
> >firewall server and an authentication server. For example, "DENY with
> >notify-admin" means that the access is rejected but the
> notification of the
> >access must be sent to admin. The TC approved to include
> this long time
> >ago.
> >
> >For the no-understandable obligations, the Polar's
> suggestion to include
> >understandable obligations in request context might be one option. It
> >definitely eliminates the case when the PEP receives
> non-understandable
> >obligation from the PDP. But I have a slight concern. What
> if there are
> >hundreds of obligations the PEP understands? Then I don't
> think it is an
> >efficient way to mandate to include all the understandable
> obligations in
> >each access request because it may make access request very
> large, even if
> >such information is irrelevant to many access requests.
> Another way would
> >be to create a communication protocol between PDP and PEP to
> exchange a
> >list of understandable obligations, but it seems outside the scope of
> >XACML. XACML should focus on what decision must be generated
> in response to
> >what decision request. Therefore,  I would prefer my
> original definition
> >that includes the case when the PEP does not understand the
> obligation.
> >
> >Michiharu Kudo
> >
> >IBM Tokyo Research Laboratory, Internet Technology
> >Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428
> >
> >
> >
> >
> >
> >----------------------------------------------------------------
> >To subscribe or unsubscribe from this elist use the subscription
> >manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> Anne
> ---------
> Anne Anderson                     Anne.Anderson@Sun.COM
> Internet Security Research Group
> Sun Labs, Burlington, MA          Phone: 781-442-0928
>
>
> ----------------------------------------------------------------
> 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