MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: summary of "Obligations rear their ugly head"
If you're like me, you've been swamped for the last week, and haven't
had the time to carefully follow the thread between Polar and Bill on
Obligations [1], which is too bad, since it's raised some excellent
points. Sooo, as a public service, I've decided to summerize what I
think the key points are, and extract what I think the lessons are. Hope
this is helpful...Bill and Polar, please correct me :)
The key point of this discussion centers around what Obligations really
mean, and what a PEP is supposed to do with them, especially in error
cases. For that matter, it's somewhat unclear exactly what all the error
cases are. A second point is what the relationship really is between a
PEP and a PDP, and based on that what a PEP should be free to do with
decisions.
At the start of the discussion, Polar raised a good question (and I'm
paraphrasing here): what does "provided that" mean in the context of
enforcing obligations at the PEP? In other words, if the spec says that
the PEP should follow the Permit/Deny decision provided that it obeys
the Obligations, what does that mean? We don't really want to push any
authorization decisions out the PEP, but that's what this sounds like.
Bill suggested that the PEP must be capable of understanding and
supporting the Obligations it is given. This doesn't mean that the PEP
must be able to take the obligated action right then (for example, it
might delay sending email if the server is unavailable, or it might wait
30 days before expiring some 30-day-valid access token). The PEP simply
must be able to undertand the obligations and know how to act on them
eventually. [Personally, I think this is the right way to think about it]
What this means is that if the PEP gets a Permit with obligations, and
if it understands the obligations, then it should Permit. If it doesn't
understand the obligations, then this is an error. The natural question,
therefore, is how is this different than Deny, and for that matter how
do you handle Deny when the PEP doesn't understand an obligation? In
general, I think we all agree that these are error cases (ie,
Indeterminate), and that the PEP should act accordingly: ping another
PDP, look up the Obligation in some service, give up with an error, or
whatever other app-specific behavior it knows.
[the meta-comment here is that Obligations are optional, and so you
don't have to use them, but that still doesn't help define what a PEP
does when it encounters an Obligation it can't understand...thus, the
comments about error handling]
Related to this, Polar raised another good issue (again, I'm
paraphrasing): what is the relationship between the PEP and PDP, and
should the PEP always obey the PDP? Bill asserted that there is some
relationship between the two, and it would be invalid for a PEP to
flat-out ignore a decision, an obligation, etc. However, it's perfectly
within a PEP's rights to balance a PDP's decision against other factors,
like the decisions from other PDPs. I think there was agreement on this
point.
One specific editorial comment that Polar suggested (and I agree with)
is that in the example showing Obligations, the text that reads
"allow...provided that an email is sent to the patient" should be
changed to "allow...with an Obligation to send email to the patient."
Whew. There were, obiously, other details in the discussion, but I think
that captures the high-order bits. Please someone chime in if I've
missed an important point (it's getting a little late <g>).
seth
[1] No, this isn't about Obligations in Rules or about determinism. I'll
respond to those issues in separate emails.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]