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 .


 

Not sure what exactly is being broken - the evaluation performed is exactly
the same - the only difference is the "automatic" type convertion function
application for this very narrow and well defined case.

Matching (member-of "blah" <designator>)  and (string-equal "blah" <implicit
string-one-and-only<designator> >)  is the same - you can compile and make
sure the type safety is satisfied just as well.  It is only a syntax issue
to allow easier use of designators/selector in target without opening up the
syntax to a full blown <apply> tree.

If you have your context precompiled and verified you index the target in
just the same way - you just write it down in a little bit diferent manner..

But I do agree that everything complicated sould go into condition - but we
already have our target structure. 

Daniel;


-----Original Message-----
From: Polar Humenn
To: Daniel Engovatov
Cc: 'Anne.Anderson@Sun.com'; XACML TC
Sent: 10/19/02 12:43 PM
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