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