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] | [List Home]


Subject: RE: [xacml] Proposed functional enhancement - Optional return of policy ids of policies applicable to request


(Note -- not sure I am able to post to this list, so specified
addressees may be the only ones receiving.) 

It is of great interest to us (DHS) to be able to answer the question of
why access was granted (or not) to a resource.  However, I wonder if it
might be useful to distinguish between the detailed analysis of which
particular rules led to a decision, vs. recording the assertion by a PDP
that a defined policy set was applied, e.g.,
homelandSecurityPolicySetv2008-08-01. Analysis of the efficiency or
effectiveness or accuracy or whatever of the policy set could be done as
a separate "design-time" process, during which the particular rule or
rules that did or didn't fire could be examined, modeled, etc. I would
see this approach as being analogous to other "standards profile"
strategies, where it is desirable to be able to confirm that the current
required profile is implemented, without having to worry with the
details of the profile. 

Martin


Martin F Smith
Chief, National Security Systems Branch
DHS Office of Intelligence and Analysis
NAC 19-410
(202) 447-3743 desk
(202) 441-9731 mobile
(800) 417-6930 pager
-----Original Message-----
From: xacml-return-839-martin.smith=dhs.gov@lists.oasis-open.org
[mailto:xacml-return-839-martin.smith=dhs.gov@lists.oasis-open.org] On
Behalf Of Craig Forster
Sent: Wednesday, August 13, 2008 9:34 PM
To: sampo@symlabs.com
Cc: hal.lockhart@oracle.com; xacml@lists.oasis-open.org
Subject: Re: [xacml] Proposed functional enhancement - Optional return
of policy ids of policies applicable to request

Hi Sampo and Hal,

This information (which PolicySet, Policy and Rules were applicable)
closely relates to audit requirements around why a certain response was
given.  An approach we could take would be to define a set of audit
obligations that return this information.

Using audit obligations would allow XACML 2.0 to have this feature as
well.
However, the requesting of this information wouldn't be per-request, it
would be enabled for the entire PDP.

Regards,
Craig

---------------------------------------------------------------
Craig Forster
Software Engineer
IBM Australia Development Labs
---------------------------------------------------------------


 

  From:       sampo@symlabs.com

 

  To:         "hal.lockhart@oracle.com" <hal.lockhart@oracle.com>

 

  Cc:         "xacml@lists.oasis-open.org" <xacml@lists.oasis-open.org>

 

  Date:       14/08/2008 11:01

 

  Subject:    Re: [xacml] Proposed functional enhancement - Optional
return of      policy ids of policies applicable to request 
 






Hal Lockhart wrote:
> This is something we talked about a long time ago and I sort of forgot
> about it. I am now proposing we add it to 3.0. If everybody is ok with
the
> idea, I will propose specific text.
>
> As a feature for administration, debugging, what if processing and
user
> performance improvement I think it would be convenient to be able to
ask
> the PDP to return a list of all the policy Ids of the policies which
were
> found to be applicable during the evaluation of a particular decision.
> Note that because of optimization, this list might not contain all the
> policies applicable to the request (if the PDP got the answer w/o
> evaluating them all). This implies that two different implementations
> might return different results.

I whole-heartedly agree with adding this feature.

Since the objective is to describe what actually was evaluated to
reach an outcome, I do not see any problem in two implementations
returning different responses if the rule set(s) was(were) written
to be nondeterministic.

For efficient implementation, "short circuit" evaluation should
be allowed where possible -- mere logging feature should not
force you to the expense of full evaluation.

Also, when folks optimize the rule sets into their internal
representations, it is common that mapping to original rules
gets a little blurred. I think we should view this policy id log
as an analog to C compiler reporting yacc source line numbers: there
is a connection, but due to optimization it is not guaranteed
to be linear. The log output would be for consumption by
human expert who understand the issues, and the tools they use.

> Basically this would require a flag in the request to indicate that
the
> Ids are requested and an element in the response to contain the list.
The
> proposal is to do this in core, not just in the SAML Req/Resp.
>
> Implementation would be optional. However, in order to do reduction,
you
> need to track this anyway.

Seems straight forward. Any chance of adding this as optional
to XACML 2.0 as well?

Cheers,
--Sampo

> Hal



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php





---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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