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] bags and targets. Forwarded message from Seth Proctor .



Even so, this appraoch breaks the whole ease of targeting policies.

This requires that you need to evaluated all your targets for every
request to make sure that you do not have an interdeterimate comming up
from some error condtion of not not having a particular attribute.

You want to take the information given to you in the request context and
select the applicable policies. Write those policies as such. If you have
special requirements such that an attribute must be present with some
value, that is a "complicated" evaluation and should go in the condition.

Otherwise, Policy Targeting is just another "hard" evaluation, and we
might as well eliminate it all together.

-Polar


On Fri, 18 Oct 2002, Daniel Engovatov wrote:

>
> We probably should discuss my suggestion.  Implicit *-one-and-only type
> transformation when selector/Designator is used as an argument that must be
> of singleton type is safe, clear and answers your concerns about its use in
> Target.  If you, indeed need one and only one argument (and any function
> requiring a sigleton does, by definition) anything else will yield
> Indeterminate (which is indeed a bad condition one should not rely upon for
> expressing the policy logic - it is there since errors do happen in our
> externalized data model and computation model and we needed a clear and
> deterministic mechanism of dealing with them).
>
> Daniel.
>
> ---------------------------------------
> a) I can't use those in the Target
> b) If I try to use an attribute whose retrieval could fail in a
>    Target, then the Target will evaluate to NotApplicable.  This
>    will happen even if a temporary network glitch was the cause
>    for the attribute retrieval failure, and even if the policy
>    has a "Deny" effect and would have caused me to deny access
>    had the attribute been available.
>
>  > I do not remember whether we agreed or even discussed my proposal to
> treat
>  > designator supplied as an argument to a function requiring a single value
>  > attribute as an implicitly wrapped in *-one-and-only type transformation
>  > (but at least several examples used around do treat it that way).
>  > Explicitly stating such an assumption will probably answer your concern -
> it
>  > does produce Indeterminate on missing attribute, when applied to a
> function
>  > requiring a singleton..
>
> That would answer only one concern.  I agree, however, that if we
> accept your interpretation, we must spell this out.
>
> Anne
> --
> Anne H. Anderson             Email: Anne.Anderson@Sun.COM
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311     Tel: 781/442-0928
> Burlington, MA 01803-0902 USA  Fax: 781/442-1692
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> 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