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] Updated policy template wiki

Steven,
Whatever information you are using to select the right template data when filling in the right template with the right data, could also be available to a PIP which would then know which attribute values to provide for any attribute designator. Or is there something I don't understand in the discussion? 

Best regards,
Erik

On 2012-10-10 03:28, Steven Legg wrote:


Danny,

On 10/10/2012 4:59 AM, Danny Thorpe wrote:

[snip]
The equivalent of dynamic policy template reduction would require setting up a PIP with the PDP to provide the appropriate template-data values for a particular attribute ID when the PDP evaluates the <AttributeDesignator>. The PIP would need to be able to distinguish between your two template cases below (Curtiss, Packard vs Curtiss, Spad). If the PIP knew the context of which policy ID an <AttributeDesignator> was being evaluated in, the PIP could make the decision of whether to return (Curtiss, Packard) or (Curtiss, Spad) to provide the semantics of the original policy template concept. Knowledge of the PDP evaluation state by PIPs is not part of the XACML spec, but could be provided by an implementation.
I could imagine manipulating the policy ID to indicate what substitution group(s) the policy belongs to. Policy template (ID = “ABC”) + parameter data set 1 => policy ID=”ABC/1”. Policy template (ID = “ABC”) + parameter data set 2 => policy ID=”ABC/2”. The policy bodies are identical, but their IDs differ.
A more generalized solution would be to tie the parameter substitution group selection to some artifact of the request (subject, resource) or the environment (PDP host organization). PIP returns parameter data set 1 for the target attribute ID if the request context also contains a “green apple” attribute, else the PIP returns parameter data set 2. PIP returns parameter data set 1 if the organization’s country is X, 
parameter data set 2 if the organization’s country is Y, etc.
But the PIP only needs to be that smart if the PDP is multi-tenant. In the use case of a shared policy (template) needing to be customized to a particular organization’s specific details (parameter data), if the PDP is dedicated to that one organization, the PIP could simply be loading the specific details (parameter data) from a config file. No need for decision branches in the PIP at all.
You only seem to be considering one possibility of use case 2 of the Policy Template Profile. I read use case 2 as allowing that the customization for a particular organization (i.e., the organization making use of the policy 
template, not the organizations that might be mentioned in the parameter
data) could involve many policy template data. Those policy template data
may overlap with the policy template data of another organization using the same template, or be completely different from the policy template data used by another organization using the same template. Use case 1 also calls for many policy template data in use at the same organization. I seem to recall it being written somewhere that the policy template data may number in the 
thousands.
For dynamic template reduction where there are multiple policy template data, we can't rely on information in the request to cause the PIP to select one 
parameter group. The PDP has to repeatedly evaluate the policy template
causing (somehow) the PIP to return a different parameter group each time, 
each parameter group corresponding to a different policy template data,
and this must occur during the evaluation of a single authorization request. 

Regards,
Steven



-Danny

*Danny Thorpe *

Authorization Architect

*Dell*| Identity & Access Management, Quest Software

Quest Software is now part of Dell.

*From:*Jean-Paul Buu-Sao [mailto:jean-paul.buu-sao@tscp.org]
*Sent:* Tuesday, October 09, 2012 1:40 AM
*To:* Erik Rissanen; Steven Legg
*Cc:* Danny Thorpe; xacml@lists.oasis-open.org
*Subject:* RE: [xacml] Updated policy template wiki

For sake of clarity I would like to rephrase the thought process.
Here is the excerpt of a policy (TAA-1.1), expressing that the subject attribute "http://schemas.tscp.org/2012-03/claims/OrganizationID"; must be in the bag {"Curtiss", "Packard"} 

     <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">

       <Apply xsi:type="AtLeastMemberOf"
functionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<Apply functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";>Curtiss</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";>Packard</AttributeValue> 

         </Apply>
<AttributeDesignator AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID"; 
DataType="http://www.w3.org/2001/XMLSchema#string"; />

       </Apply>

       (etc...)

     </Condition>
Here is the excerpt of a policy (TAA-1.2), expressing that the subject attribute "http://schemas.tscp.org/2012-03/claims/OrganizationID"; must be in the bag {"Curtiss", "Spad"} 

     <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">

       <Apply xsi:type="AtLeastMemberOf"
functionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<Apply functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";>Curtiss</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";>Spad</AttributeValue> 

         </Apply>
<AttributeDesignator AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID"; 
DataType="http://www.w3.org/2001/XMLSchema#string"; />

       </Apply>

       (etc...)

     </Condition>
The two policies (TAA-1.1 and TAA-1.2) are similar, with the exception of the hard-coded values of the string bags used by the AtLeastMemberOf function. The idea is to have only one policy that does not contain these hard-coded values. Instead we have a construct that would substitute the appropriate values. In the example above: {“Curtiss”, “Packard”} for TAA-1.1, {“Curtiss”, “Spad”} for TAA-1.2.
My initial proposal was to using the element <AttributeValue> without qualifying its contents values, but by specifying a ParameterId attribute, that would allow to substitute the appropriate values: 

     <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">

       <Apply xsi:type="AtLeastMemberOf"
functionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<Apply functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue ParameterId="organizations" DataType=http://www.w3.org/2001/XMLSchema#string/> 

         </Apply>
<AttributeDesignator AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID"; 
DataType="http://www.w3.org/2001/XMLSchema#string"; />

       </Apply>

     (etc...)

     </Condition>
I understand that instead, and in order to achieving the same effect, Erik’s proposal is to replace the <AttributeValue ParameterId=…> construct with the more standard <AttributeDesignator> construct, given 
something like:

     <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">

       <Apply xsi:type="AtLeastMemberOf"
functionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<Apply functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeDesignator CategoryId="urn:oasis:names:tc:xacml:1.0:policy:" AttributeId="organizations" 
DataType="http://www.w3.org/2001/XMLSchema#string"; />

         </Apply>
<AttributeDesignator AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID"; 
DataType="http://www.w3.org/2001/XMLSchema#string"; />

       </Apply>

     (etc...)

     </Condition>
If my interpretation is correct (at least on the intent, not on exact syntax; Erik, I apologize if I totally 
missed your point), then some questions arise:
A.1) How would the authorization engine know where to go and fetch the desired values (i.e. from the TAA-1.1 
template-data or the TAA-1.2 template-data)?
A.2) The <AttributeDesignator> construct was, so far, meant to retrieve attributes values from (Subject, Resource, Environment) attributes. Are we introducing the possibility for the same construct to also retrieve attribute values from (policy-template) attributes? If so we need to make it explicit on the 
specification, I would think.

B) Can the two use-cases called out at the beginning of
[https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile] be supported by <AttributeDesignator>?
I assumed that use-case 1 requires a static reduction, that happens far before any actual authorization decision; hence <AttributeDesignator> cannot be used for the purpose of parameterization. If my assumption is correct, then we need a different mechanism to support use-case 1, which is damageable. My proposal was 
to find a single syntax that would equally support both use-cases.

Thanks,

Jean-Paul

-----Original Message-----
From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Tuesday, October 09, 2012 08:32
To: Steven Legg
Cc: Jean-Paul Buu-Sao; Danny Thorpe; xacml@lists.oasis-open.org <mailto:xacml@lists.oasis-open.org> 
Subject: Re: [xacml] Updated policy template wiki

Steven,
I am arguing against the whole concept of a template, thus there is no Policy Template Engine in my proposal.
What I am trying to say is that instead of adding a Policy Template Engine to the PDP before the policy is evaluated by the XACML engine, you can just use a regular XACML policy in the XACML engine.
You can solve the same use case this way. Say that you want a template which has a parameter called "foo" and then a Policy Template Engine which substitutes "foo" with values before the XACML engine. Instead you can have a regular XACML policy with attribute designator "foo" and a PIP which provides the value which 
would have been provided by the policy template engine.

Best regards,

Erik

On 2012-10-09 02:46, Steven Legg wrote:






Erik,







Sorry, I read too much into what you were saying. Please disregard my



previous response.







On 8/10/2012 5:38 PM, Erik Rissanen wrote:



Steven,







Yes, just replace all parameters with attribute designators.







An issue with using attribute designators as parameters is that there



is ambiguity for the Policy Template Engine to resolve. Some attribute



designators in the policy template are "real" and are preserved as is,



and the other attribute designators are actually parameters that need



to be replaced by a bag of attribute values from the policy template



data.







Your example only has one parameter as a designator and that



designator uses the same URI for the Category and AttributeId. Were



you intending that equivalence as a way of distinguishing an attribute



designator that is actually a parameter, or is it just because you had



to put something in the Category ? A Policy Template Engine could



always look in the policy template data to work out which designators



are really parameters, but I think it would be better if it were clear



from the designator. I suggest using a special category URI just for



parameters.







The attribute designators that are actually parameters should always



use MustBePresent="true" so that an implementation that blindly



evaluates a policy template as a normal policy will appropriately



return an indeterminate decision.







It seems we have three proposals for representating parameters in



policy



templates:







(1) Just use attribute designators. This means that targets can't have



parameters, but on-permit-apply-second can be used to get the same



effect.



Policy template data writers can determine whether a parameter is



single-valued or multi-valued by seeing whether the corresponding



attribute designator is wrapped in type-one-and-only.







(2) <ValueParameter> and <BagParameter> elements. Targets can have



value parameters, but not bag parameters, though



on-permit-apply-second can be used to get the same effect. It's



obvious to policy template data writers what the parameters are and



whether a parameter is single-valued or multi-valued.







(3) ParameterId XML attribute on <AttributeValue> elements. It's



reasonably obvious to policy template data writers what the parameters



are. An additional XML attribute to indicate whether the parameter is



single-valued or multi-valued would make this solution cleaner.



Targets can have value parameters. Targets could also have bag



parameters provided the target is transformed by the Policy Template



Engine. Alternatively, bag parameters in targets could be disallowed



because on-permit-apply-second can be used to get the same effect.







I don't see a compelling need for transformations of conditions.



Proposals



(1) and (2) don't lend themselves to transformations, but it could be



done.



The difference in the proposals is mostly around the syntax for



representing parameters.







Regards,



Steven











I don't understand why you need to evaluate the template twice. I



tried to understand it from the wiki, but to me it all looks like



simple value substitution, which can handled better with attribute



designators.







Best regards,



Erik







On 2012-10-08 04:32, Steven Legg wrote:







Erik,







On 5/10/2012 6:03 PM, Erik Rissanen wrote:



Jean-Paul,







I put in one such example on the wiki page. Search for



"on-permit-apply-second" and you will find it.







This strategy only works if there is one policy template data for



the policy template. In general, there may be many policy template
data per policy template. The example in the wiki has two: TAA-1.1 and TAA-1.2. 






Although you didn't do it, I assume you meant to replace the



parameters in the condition with attribute designators as well,



i.e., designators for "organizations", "nationals" and "workEfforts".







The policy needs to be evaluated twice. The first time the attribute



designator for PolicyIdOnResource needs to return



"urn:curtiss:ba:taa:taa-1.1", the designator for "organizations"



needs to return the bag of { "Curtiss", "Packard" }, the designator



for "nationals" needs to return the bag of { "US", "GB" }, and



"workEfforts" needs to return { "DetailedDesign", "Simulation" }.



The second time, PolicyIdOnResource needs to return



"urn:curtiss:ba:taa:taa-1.2", "organizations" needs to return {



"Curtiss", "Spad" }, "nationals" needs to return { "US", "FR" } and



"workEfforts"



needs to return { "Integration", "Simulation" }.







Of course, we don't currently have a way to cause a policy to be



evaluated multiple times with the attribute designators returning



different bags each time. For one thing, the result of an attribute



designator is fixed for the entire duration of the processing of an



authorization request. The expansion of the policy template into a



policy template instance for each policy template data achieves the



same end.







The use of on-permit-apply-second is a good idea for removing the



need for any special processing of parameters in targets.







Regards,



Steven











Best regards,



Erik







On 2012-10-04 23:01, Jean-Paul Buu-Sao wrote:







Greetings,







Apologies for missing the call today, as I was in a TSCP event,



together with Gerry and David of Axiomatics.







I have been much interested in the last findings, and agree that



if the “template” property that we are (all, I think) looking for



could be achieved with standard the <AttributeDesignator>



construct, rather than introducing new concepts, then this would



be for the better.







May I suggest that, in order to verify this assertion (so to



speak), some folks, such as Erik or Danny, would be kind enough to



propose an alternate proposal to the sample found on our Wiki
(https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile%20Examples)? 


By the way, as a word of



caution, please disregard the in-correctness of the XCAML 3.0 of



section 1. of the example (yes the devil is in the details, and



David shown me how this example could be made compliant).







Thanks in advance,







Jean-Paul







*From:*xacml@lists.oasis-open.org
[mailto:xacml@lists.oasis-open.org] <mailto:[mailto:xacml@lists.oasis-open.org]> *On Behalf Of *Danny Thorpe 


*Sent:* Thursday, October 04, 2012 20:11
*To:* Erik Rissanen; xacml@lists.oasis-open.org <mailto:xacml@lists.oasis-open.org> 


*Subject:* RE: [xacml] Updated policy template wiki







When the original proposal for policy templates was brought



forward, I noted that simply replacing a single AttributeValue



element with a list of values from the policy template <Parameter>



would fail in <Match> expressions, since <Match> is very explicit



about one value, one designator/selector.  I offered a transform



to help produce valid match expressions.







AttributeDesignator does provide similar



“insert-multiple-values-here” operations to the policy template



substitution behavior, but I believe the suggestion of policy



parameterization came up because of situations in which



AttributeDesignator cannot be used. Comparing an  attribute



against a static list of test values (specific to an organization



or location and applied to a generic policy), for example, is a



many-to-many comparison, but cannot be expressed in a <Match>



element.







As we discussed on the TC call today, we’re finding more



difficulties with parameter substitution the deeper we dig. Steven



Legg noted in an earlier email that some Xacml functions that take



single <AttributeValue> won’t work if multiple values are dropped



in to replace the <AttributeValue>. This means some sort of



expression transform will be necessary in condition expressions as



well to move policy templates forward.







In light of these increasing complexities and challenges, I’m



beginning to agree with you that perhaps the policy template use



case can better be addressed using the existing



<AttributeDesignator>.







This would mean:







1.Giving up parameterization behavior in <Match> expressions and



moving that logic into conditions using <AttributeDesignator> to



reference an attribute ID representing the parameterization data.







2.Moving parameterization data from a static policy generator step



to a PIP to fill <AttributeDesignator> references to a particular



attribute ID with parameterization data in the PDP at auth request



evaluation time.







Using <AttributeDesignator> instead of policy templates does



impact the use case quite a bit because populating PIP data is not



part of the Xacml spec. Policies could be shared between



organizations per the use case, but how the parameterization data



is applied to those policies would become a vendor-specific



implementation detail.







I can see the attraction of parameterizing policies to allow



up-front synthesis of specific policies, but as we say “the devil



is in the details.” The details are winning. :/







-Danny







*Danny Thorpe *







Authorization Architect







Dell | Identity & Access Management, Quest Software







Quest Software is not part of Dell.







*From:*xacml@lists.oasis-open.org



<mailto:xacml@lists.oasis-open.org>
[mailto:xacml@lists.oasis-open.org] <mailto:[mailto:xacml@lists.oasis-open.org]> 


<mailto:[mailto:xacml@lists.oasis-open.org]> *On Behalf Of *Erik



Rissanen



*Sent:* Thursday, October 04, 2012 4:42 AM
*To:* xacml@lists.oasis-open.org <mailto:xacml@lists.oasis-open.org> 


<mailto:xacml@lists.oasis-open.org>



*Subject:* Re: [xacml] Updated policy template wiki







All,







I still fail to see why this is useful.







If you take a policy template, and replace each <Parameter> with



an appropriate <AttributeDesignator>, then you get a regular XACML



policy, and the PEP/PDP can "fill in"



the "template" at runtime using normal XACML attributes.







Why do we need a new standard? In particular I would be opposed to



"implementation option C", that is a PDP would construct the



policy from the template at runtime.



That's lots of heavy machinery for no gain.







Best regards,



Erik







On 2012-09-20 20:25, Danny Thorpe wrote:







    I’ve updated the policy template wiki



(https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile)



    with text about required Match expression rewriting in



parameter substitution and optional use of



    AttributeDesignators and AttributeSelectors in Parameter data



in dynamic policy template reduction



    implementations.







    -Danny







    *Danny Thorpe *







    Product Architect | | *Quest Software*- /Now including the



people and products of BiTKOO/ |



www.quest.com <http://www.quest.com> <http://www.quest.com>

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