[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Validity checking between PEP and PDP
Tim, More about the ballot you drafted ... >The question arises as to how many assertions, and of what types, >can appear in a single message. Again, let's focus on the message >between the PEP and the PDP. The implications of our decision for >the other messages should become clear. > ... >On {AP-4}, I think the PEP should ask a specific question ... "Is >the Principal that is authenticated by this authenticator permitted to > perform such-and-such an action?" The "authenticator" must be one > of a number of things ... >password, >challenge/response pair, >document/signature pair, >authentication assertion. (In this latter case, the Principal has > authenticated simply by presenting the assertion). Actually, I think the case of the PEP-to-PDP exchange is quite different than other exchanges with respect to validity checking of input. Your answer to {AP-4} brought this into sharp relief for me. I have a couple of opinions on validity checking which I present here. Firstly, I'd phrase the question that the PEP poses quite differently than you did. My version is: Is the requestor that has the following attributes permitted to perform such-and-such an action? In other words, the interface to the PDP doesn't deal with authentication. It is up to the PEP to decide whether or not the requestor is authenticated "properly". (The PDP might take "authentication method" as an input attribute though.) Going on with this idea, I don't think that an Authorization PDP deals with validating attributes either! It just takes them in and spits out an answer. There might be a PDP for validating attributes. But this is separate from the Authorization PDP. In my view, the interface from the authZ PEP to the authZ PDP should deal with "naked" attributes, and not assertions. Leave the intelligence about what constitutes a "valid" attribute elsewhere. The advantage of the separation I'm suggesting is that it allows for a PEP to collect attributes for an authZ decision from a variety of "asserting parties", each of which may have different characteristics with respect to validity checking. I think this is an important feature. I know that I already face situations where I will need to collect attributes from different sources, and perform different validation checks depending on the source. I definitely do not want to encode this intelligence in my authorization PDP, and I want a consistent, simple interface between the PEP and authZ PDP. My 2 cents, Marlena Erdos IBM/Tivoli
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC