OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Problems with XACML and time


Satoshi Hada wrote:
> >>This is especially odd since XACML defines time-equal to be
> >>equivalent to "the 'op:time-equal' function [XF Section 8.3.14]."
> >>This function *does* allow comparing times when one of
> >>the times has a time zone and one does not. It simply
> >>specifies that the time without a time zone should be
> >>assigned an implicit time zone (generally the local time
> >>zone).
> 
> Yes, so I think every PDP should have
> an implicit time zone (the default time zone).

I expect that most PDPs do this already. Ours certainly does.
However, this only works with time-equal. XACML defines all the
time comparison functions (like time-less-than) in terms of the
order relations defined in XML Schema, which don't allow you
to compare a time with a time zone to a time without a time zone.

> >> Can this problem be fixed by specifying a time zone for the
> >> times specified in the policy (the AttributeValues)? That
> >> has the disadvantage of tying the policy to the specific
> >> time zone of the PDP, meaning that you can't use one policy
> >> to handle multiple time zones. In fact, you must update the
> >> policy whenever you change to Daylight Savings Time. But set
> >> that aside. Look at policy2.xml, which adds a time zone.
> 
> I agree on this disadvantage.
> 
> However, I think we can specify an implicit time zone (the
> default time zone) in each PDP, not in the policy. I mean
> that all PDPs should be initialized with the default time zone
> so that both "current-time" and times with no time zone have
> the default time zone. I think that this solves the problem.
> Or am I missing something?

This would solve one problem (the problem of having to specify
a time zone for every explicit time in the policy), but I think
that a spec change would be required. The current language
certainly doesn't imply that this should be done. The simplest
way to make this change would be to change the definition of the
XACML time comparison functions to refer to XML Query instead of
XML Schema, as the time-equal function already does.

This solution does not solve the problem mentioned in this
paragraph from my original email:

> Making this change does fix the problem, unless you are in
> the Far East. If midnight GMT is between 9:00 AM and 5:00 PM
> in the PDP's time zone, then the policy always denies
> access. Surprising, eh? The reason is that the order
> relation specified by XML Schema for times says that you
> normalize the times to GMT and then compare them, with
> midnight GMT being the earliest time and 23:59:59 being
> the latest. If midnight GMT is noon local time, then the
> revised policy will only grant access is the current time
> is after 9:00 PM GMT and before 5:00 AM GMT. That can't
> ever happen.
> 
> So how can this problem be addressed? If midnight GMT is
> between 9:00 AM and 5:00 PM in the PDP's time zone, you
> must rewrite the policy to say that access is granted if
> the current time is after 9:00 AM *OR* before 5:00 PM in
> the local time zone. That's pretty odd!

In my view, the best solution to this problem is the one
described in my message:

> 2) Define a new time-in-range function that takes three time
> arguments and returns true if the first one falls between
> the other two (on or after the second time and on or before
> the third time). If no time zone is specified for the second
> or third arguments, treat them as if they are in the time zone
> of the first argument. Then you could say
> 
> time-in-range(current-time, 9:00:00, 17:00:00)
> 
> to check whether the PDP-local time is between 9 AM and 5 PM
> in the PDP-local time zone (regardless of where the PDP-local
> time zone is relative to GMT).
> 
> This would make it easy to solve the most common problem and
> get it right without having to understand a lot about
> times and dates, spend a lot of time changing your policy
> for different time zones, etc.

I hope this clears things up.

Thanks,

Steve

S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]