[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Summary of the discussion on WI#10: Parameter for algorithm
Hi, Polar >this proposal seems to limit you to ONE parameter per rule. Is that correct? No. It is possible to assign two parameters on a rule. For example, <Policy algid="priority-rule-combo-algo"> <CombinerParameters> <CombinerParameter ParameterName="priority"> <AttributeValue DataType="...:integer">2</AttributeValue> </CombinerParameter> <CombinerParameter ParameterName="weight"> <AttributeValue DataType="...:integer">10</AttributeValue> </CombinerParameter> </CombinerParameters> <Rule RuleId="R1"> ... </Rule> </Policy> I think that the policy writer who is going to write parameters must know how each parameter is assigned to which rule, and its semantics. I feel that some policy authoring tool must support this type of policy authoring process. Actually, original proposal came from Simon and the sprit behind his proposal is that the semantics of each parameter is up to each combining algorithm. >For example, do we want the capability to have two or XACML parameters >associated with each rule? Probably yes, for flexibility. For example, if each rule has meta-information such as creater and issue-date, and the evaluation algorithm uses these two values for determining the priority (Alice's rule takes precedence over Bob's rule and newly created rule takes precedence) , we therefore need two parameters per rule. Using the same policy example, <Policy algid="priority-rule-combo-algo"> <CombinerParameters> <CombinerParameter ParameterName="creater"> <AttributeValue DataType="string">Alice</AttributeValue> </CombinerParameter> <CombinerParameter ParameterName="issue-date"> <AttributeValue DataType="date">Jan 30 2004</AttributeValue> </CombinerParameter> </CombinerParameters> <Rule RuleId="R1"> ... </Rule> </Policy> Another possibility is to specify these values as local schema: <Policy algid="priority-rule-combo-algo"> <CombinerParameters> <CombinerParameter ParameterName="certificate"> <AttributeValue DataType="urn:mycert" > <cert:credential> <cert:subject-name>Alice</cert:subject-name> <cert:issue-date>Jan 30 2004</cert:issue-date> </cert:credential> </AttributeValue> </CombinerParameter> </CombinerParameters> <Rule RuleId="R1"> ... </Rule> </Policy> >The later approach can work semantically within type system. That approach >will be more syntax restrictive, and it is bit better for type safety. I am perfectly ok with the type-oriented system because XACML policy IS the type system. I think the above examples also conforms to your proposed schema. I have one concern about your suggestion to fix the mechanism how to assign a combiner parameter to each rule. It may be the case that <Policy> (not <Rule>) needs some parameters. So we would have to distinguish both. Easier way would be to add one more attribute "ParameterRef"that specifies the target of the parameter. For example, <Policy PolicyId="P1" algid="priority-rule-combo-algo"> <CombinerParameters ParameterRef="P1"> <CombinerParameter ParameterName="creater"> <AttributeValue DataType="string">Alice</AttributeValue> </CombinerParameter> </CombinerParameters> <CombinerParameters ParameterRef="R1"> <CombinerParameter ParameterName="creater"> <AttributeValue DataType="string">Bob</AttributeValue> </CombinerParameter> </CombinerParameters> <Rule RuleId="R1"> ... </Rule> </Policy> The first parameter is for policy "P1" and the second parameter is for rule "R1". It frees us from the problems where to write and how to assign. Best, Michiharu Polar Humenn <polar@syr.edu> To 2004/03/26 04:22 Michiharu Kudoh/Japan/IBM@IBMJP cc "'xacml@lists.oasis-open.org'" <xacml@lists.oasis-open.org> Subject Re: [xacml] Summary of the discussion on WI#10: Parameter for algorithm Michiharu, If it is the intent of combining algorithm to associate parameters with a rules, this proposal seems to limit you to ONE parameter per rule. Is that correct? The difference is the effective semantic type of the combining algorithms. For example, do we want the capability to have two or XACML parameters associated with each rule? (Params (Param priority 2)(Param weight 10))(Rule ...) (Params (Param priority 3)(Param weight 50))(Rule ...) Please, excuse me for not using <XML/> :) The other question is that do we want to bring the parameter values into the XACML type system? The two questions are related as if we take the approach with the ability to associate just ONE parameter per rule, then the combining algorithm must perform ALL the parsing of the parameter content, in case it does want multiple information items per rule. Also, no referencing of variable expressions can be done, because the combining algorithm will/should not have access to the evaluation environment (that's different than the ReqeustContext Environment). However, if we take the approach that a Parameter(s) MUST be an XACML Expression(s), then the expression(s) may be evaluated before being passed to the combining algorithm. The later approach can work semantically within type system. That approach will be more syntax restrictive, and it is bit better for type safety. How about: <xs:element name="CombinerParameters" type="xacml:CombinerParametersType"/> <xs:complexType name="CombinerParametersType"> <xs:sequence> <xs:element ref="xacml:CombinerParameter" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <!-- --> <xs:element name="CombinerParameter" type="xacml:CombinerParameterType"/> <xs:complexType name="CombinerParameterType"> <xs:sequence> <!-- Change Is Here --> <xs:element ref="xacml:ExpressionType" minOccurs="0" maxOccurs="unbounded"/> <!-- --> </xs:sequence> <xs:attribute name="ParameterName" type="string" use="required"/> </xs:complexType> 2. Example policies would be: <Policy algid="priority-rule-combo-algo"> <CombinerParameters> <CombinerParameter ParameterName="priority"> <AttributeValue DataType="...:integer">2</AttributeValue> </CombinerParameter> <CombinerParameter ParameterName="weight"> <AttributeValue DataType="...:integer">10</AttributeValue> </CombinerParameter> </CombinerParameters> <CombinerParameters> <CombinerParameter ParameterName="priority"> <AttributeValue DataType="...:integer">10</AttributeValue> </CombinerParameter> <CombinerParameter ParameterName="weight"> <AttributeValue DataType="...:integer">50</AttributeValue> </CombinerParameter> </CombinerParameters> <Rule effect="permit">... rule 1...</Rule> <Rule effect="permit">... rule 2 ...</Rule> </Policy> and <Policy algid="priority-rule-combo-algo"> <CombinerParameters> <CombinerParameter ParameterName="priority"> <AttributeValue DataType="...:integer">2</AttributeValue> </CombinerParameter> <CombinerParameter ParameterName="weight"> <AttributeValue DataType="...:integer">10</AttributeValue> </CombinerParameter> </CombinerParameters> <Rule effect="permit">... rule 1...</Rule> <CombinerParameters> <CombinerParameter ParameterName="priority"> <AttributeValue DataType="...:integer">10</AttributeValue> </CombinerParameter> <CombinerParameter ParameterName="weight"> <AttributeValue DataType="...:integer">50</AttributeValue> </CombinerParameter> </CombinerParameters> <Rule effect="permit">... rule 2 ...</Rule> </Policy> Note, that in Michiharu's example, <CombinerParameters> <CombinerParameter ParameterName="priority"> <AttributeValue DataType="...:integer">10</AttributeValue> </CombinerParameter> </CombinerParameters> <CombinerParameters> <CombinerParameter ParameterName="priority"> <AttributeValue DataType="...:integer">50</AttributeValue> </CombinerParameter> </CombinerParameters> and <CombinerParameters> <CombinerParameter ParameterName="priority"> <AttributeValue DataType="...:integer">10</AttributeValue> </CombinerParameter> <CombinerParameter ParameterName="priority"> <AttributeValue DataType="...:integer">50</AttributeValue> </CombinerParameter> </CombinerParameters> are really considered equivalent. In my version, they are distinct entities. Cheers, -Polar > 3. Some concerns (raised by Polar) > > Q1 How flexible should we allow for the combiner parameter? No limitation? > Q2 Should we provide a way to use XACML useful syntax (reference, > expressions etc.) for specifying combininng parameters? > > There are two ways to address the above issues: > - No further syntactical limitation for combiner parameter > - Enforce more restriction on syntax for combiner parameter > (XACML-compliant syntax e.g. attribute value etc.) > > Best, > Michiharu > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php . > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]