[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Groups - XACML 2.0 Interop Scenarios Version 0.10 (xacml-2.0-core-interop-draft-10-06.doc) uploaded
This document is in progress and is intended to be used for XACML 2.0
Interop Event planned to be conducted at and during the Burton Catalyst
Conference in San Francisco on Thursday, June 28, 2007.
It is expected there will be regular updates to this doc over the next 3
weeks to further refine and finish scenario details.
The document should be self-explanatory, however the following cover note
was sent to give context to the current version:
Attached is an update to scenario 2 which I think captures the whole
concept. In addition to what was in the previous doc described in
the email below, I made the following changes, which I think will
have the intended effects. I plan to update this again on Monday
pending some additional feedback on the correctness of the
approach. In any event, here are the changes:
- A PolicySet has been added to section 2.3.1.2.1 which is intended
to put structure around Rules 2,3,4,5 which are listed in that
same section preceding the PolicySet.
- The PolicySet contains 2 Policies, and it uses a permit-overrides
PolicyCombiningAlgId, so my assumption is if the first Policy
evaluates to Permit (this is policyid:02, which is that both the
trade-limit and credit-ext are within threshold and no approval
needed) then things are done and only policyid:02 will have been
evaluated found to be Permit and returns the same 3 Obligations
we have been doing all along.
- If the first Policy (02) does not Permit, which is the case if
either or both of the 2 thresholds are not met, then the 2nd
policy, which has id policyid:06 is evaluated. This is a deny-
overrides policy and since neither of the first two rules will
produce a Deny then they both should be evaluated. If ruleid:3
finds that the trade limit is exceeded and the request-trade-
approval is true then it Permits and adds a trade-approval
Obligation. Similarly if ruleid:4 finds the credit limit is
exceeded and the request-credit-ext-approval is true then it
Permits and adds a credit-ext-approval Obligation.
- At this point we know at least one of the limits was exceeded, and
we know if any limit that was exceeded was accompanied by a
corresponding approval request, then the appropriate Obligation
was added. However, we have not yet determined if when either of
the limits was exceeded that the corresponding approval was NOT
requested. If this is the case, then a Deny will be issued by
Rule 5, which will cancel out any positive results from
rules 3 or 4. Rule 5 as a Deny contains its own set of FulfillOn
Deny Obligations to return to the caller.
- Otherwise if Rule 5 does not produce a Deny, then we finish up
policy:06 by adding the 3 display obligations for Permit in
addition to any approval obligations picked up by rules 3 and 4.
I think this might be a reasonable structure that achieves the intended
objective. If it is, then I also expect that we will be able to find a
fair amount of optimizations to clean things up a bit. Comments welcome.
Thanks,
Rich
Rich Levinson wrote:
Hi All,
This is still in progress, but it is taking shape, so people can evaluate
the direction it is headed. On the one hand it seems a bit complex
because of all the xml, but on the other, the basic logic is straight-
forward in terms of conditions to evaluate and flags to set.
The basic algorithm I am working for scenario 2 is the following.
First I am redoing the logic of Rule 1 in these rules except here
the action is "Buy".
With that foundation, the following algorithm is being mapped:
buy-total = buy-num-shares times buy-offer-price
if ( (buy-total < current-credit) and
(buy-total < trade-limit) )
Permit
else
if ( (buy-total >= current-credit) and
(req-credit-ext-approval = "true") )
Permit with obligation to approve credit
if ( (buy-total >= trade-limit) and
(req-trade-approval = "true") )
Permit with obligation to approve trade
final
if Permit then permit
if Permit w oblig to ext credit then add credit-ext-obl
if Permit w oblig to approve trade then add trade-approve-obl
else deny
I have found that to have the 3 mixes of obligations, 3 policies are
needed. Therefore, what has been added to section 2.3.1.2.1 are Rule 2,
Rule 3, and Rule 4. They all have permit-overrides, which enables Rule 2
to override everything since the credit and trade limits are met. A
little more is required for Rules 3 and 4 since either one can kill the
deal if it fails. So, I think there may be a PolicySet required here.
In any event, I think the rule is pretty close. It is complex enough to
be interesting, yet not so complex as to cause total confusion.
Comments welcome.
Thanks,
Rich
-- Rich Levinson
The document named XACML 2.0 Interop Scenarios Version 0.10
(xacml-2.0-core-interop-draft-10-06.doc) has been submitted by Rich
Levinson to the OASIS eXtensible Access Control Markup Language (XACML) TC
document repository.
Document Description:
This document is in progress and is intended to be used for XACML 2.0
Interop Event planned to be conducted at and during the Burton Catalyst
Conference in San Francisco on Thursday, June 28, 2007.
It is expected there will be regular updates to this doc over the next 3
weeks.
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=24232
Download Document:
http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/24232/xacml-2.0-core-interop-draft-10-06.doc
PLEASE NOTE: If the above links do not work for you, your email application
may be breaking the link into two pieces. You may be able to copy and paste
the entire link address into the address field of your web browser.
-OASIS Open Administration
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]