[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: A note about PDPs
Dear Core Colleagues, I've done a bit of looking around for definitions of "PDP". This search was very very far away from exhaustive (I used Google), but what I did find was in accord with my take on what a PDP is. I also looked around for notions of "policy decision" in general. Policy decisions cover a huge range of topics and policies. Because of time limitations I decided to not review the sources that Jeff cites. (I figure he's done that already and some aren't so easily available.). So my sources aren't official standards bodies (very far from it). Even so, I think/hope you'll find the discussion below persuasive. I'm going to show one definition of PDP that I think fits well; then talk about the existing definition and why I think we have some confusion about the role of the PDP in an authorization decision; and then I'm going to segue into a couple examples about the use of a PDP in validating attribute assertions. It is this use i.e. the need to validate attribute and authN assertions that calls for a different PDP than that used in authorization decisions. A Definition Marlena Likes/ PDP: A third party system responsible for handling policy decisions on behalf of PEPs. [This definition is from "Orchestream,a global leader in the development of software for activating services on and enhancing the performance of Internet Protocol (IP) networks."] The Current Glossary Definition/ (a) A [system] entity that makes policy decisions for itself or for other system entities that request such decisions. [31] (b) Synonymous with Access Control Decision Function. [10] Here is part of the source of the confusion. "b" refers specifcally to an access control decision function (ACDF). If we look at the definition for the ACDF, we get: "A specialized function that makes access control decisions by applying access control policy rules [JDH1] to an access request, access control decision information (of initiators, targets, access requests, or that retained from prior decisions), and the context in which the access request is made [10]." Note that the only policy mentioned in the ACDF definition is access control policy. This is an important part of the SAML space and the overall policy space but it is by no means encompassing. Some Examples of Non-authZ Policy and Policy Decisions/ In the case of SAML, part of the deal is "policy" about authN assertions and attribute assertions. Here's a example: Let's say the relying party is Brown Univer sity and the attribute authority(AA) is owned and controlled by MIT. One of the attribute assertion policies Brown might use with respect to the MIT AA is, "Accept 'enrolled in' attributes about MIT courses but don't accept "enrolled in" attributes that refer to classes at other universities." This might seem contrived but imagine an AA that is a clearinghouse for information from a number of sources. The relying party's policy might enumerate for which sources the AA is considered to be authoritative and under what conditions. A real-life example of this is American Express Travel as a clearinghouse of information from airlines. I've learned from hard experience that *my* policy as a relying party in bad weather, is to get AMEX to call the airline directly instead of using the information that is apparently available "on screen". How Does this Relate to SAML's Model/ In my opinion, it is important to keep separate the notions of policy about attribute assertions, and policy for authZ decisions. (I tend to think that policy about authN assertions might be lumped in with that for attribute assertions but logically it is separate too.) I think this separation is not just conceptual but will have reflection in the formats we decide on for the authZ decision question. Why? Well, usually policy about attribute and authN assertions relates very much to the packing of the information. There tends to be lots of policy about authenticating the asserting party. In the case of digital signatures, there are all the usual policy questions about revokation (e.g. do you check for revokation each time or rely on cached information). I don't think that the authZ decision question should drag along the packaging from the attribute assertions. (Or at least, this should be only an option). I tend to prefer unpackaged attributes because that let's me as a resource manager use attributes from various sources that have different packaging in my authZ decision question. That's it. Two references to things I looked at are below. I picked representative 'interesting ones' for inclusion here. (If you search on "policy decision" you'll get a ton of stuff back. Many but not all of the computer-related ones concern either validation decisions or authorization decisions.) Let me know if this helps, and where we go from here. Regards, Marlena PS I apologize for the lateness of this note. A business trip where I had little net access is partially to blame. PPS I can point to more formal examples of policy decision for validation (e.g. XKMS) if needed. 1) Addition of Device Class to Agent Options http://search.ietf.org/internet-drafts/draft-ietf-dhc-agentoptions-device-class-01.txt The cable modem signals its device class information to the Relay Agent using DOCSIS signalling, and the Relay Agent forwards the device class information to the DHCP Server which can then make a policy decision based on it. ... . DHCP servers MAY use the Device Class for IP and other parameter assignment policies for cable modems. [This one is interesting because the policy decision is neither validation nor authorization, but is yet computer-related.] 2) Therapeutic Products Program, Health Canada http://www.hc-sc.gc.ca/hpb-dgps/therapeut/zfiles/english/y2k/y2k_validation_e.html [This one concerns a policy decison relation to validation of procedures, processes, and materials for producing drugs.]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC