[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] Re: env attributes
On Wed, 23 Oct 2002, Daniel Engovatov wrote: > > > On Wed, 23 Oct 2002, Anne Anderson - Sun Microsystems wrote: > > > Except that I believe we say explicitly that "current-time", etc. is the > > time at the PDP. How is the PEP supposed to know the time at the PDP? > > Maybe we need current-PDP-time, etc. and current-PEP-time, etc. :-) > > >The PEP is not supposed to know the time at the PDP. The PEP should fill > >those values with the time relavant to the access decision. The XACML > >writer expects those values to correspond with the time for which the > >access decision applies. > > Disagree. For time based policy having the time passed in is not > always safe. Well, for time based (or time critical?) policy as you suggest, you would make sure that your PEP to PDP configuration was as "real-time" as you could make it. That would mean that the PEP would supply the time of the access decision, and your evaluation strategy of the PDP would process within your realtime constraints. > If it is needed - it is easy to do, just add an attribute, but if you > are going to have a build in time it has to be server side for > auditing and safety. For auditing and safety, your PDP could check to see if the time supplied in the request is within acceptable constraints before and/or after the decision is processed. This approach is common in authentication mechanisms, such as Kerberos. You also may want to ask about access decisions that are not of the actual current time, but at some time in the future. For example, as a pure client of a PDP, you may want to know if A has access to R five minutes from now, such that the decision governs how a request gets processed. To make sense of that, the policy must be written as if it were processing the given time as the current time. Alternatively, to address your time based policy approach, the PEP may not supply the time, but the "request context builder" would. Being that the request context is this a "notion" more than it is a concrete request structure, we can just state that the current time is supplied in the request context. However, whenever the PDP it asks for the current-time attribute, it gets it from the request context, and the request context builder can assign that attribute the current time at that moment, just as if were a "weight" attribute pulled from Daniel's database. However, I would suggest, once it is assigned it doesn't change during the evaluation! So, in implemenation the values given to the current time attributes can be as static and dynamic as you want it to be. And in the standard, having it come from the request context addresses both concerns, without much problem. Having the PDP generate current-time on the fly isn't much good if policies take a long time to evaluate and you cannot guarrantee when they are evaluated, and doesn't address being able to ask access decisions about the future or even the past. "Was John allowed in the building at 6pm yesterday?" Also, for analysis and testing to make sure that the policy is doing what you think it ought to do: Can "Employees get in the building at 7pm tonight"? -Polar > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC