MHonArc v2.5.2 -->
xacml message
[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