[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] request's attribute assertion lifetime?
I understand all the arguments, except that if you want to run scenarios where you want to test the access control decision in some point in the future by playing with the environment's notion of time, you're unable to note the possible expiration of the attribute assertions... Furthermore, if we move to a model where we will accept individual authorization assertions as policy statements, and with these assertion is a validity interval associated, then we won't be able to store them in the database but will be forced to revalidate them before we feed them to the PDP/PAP every single time we use them. It will also allow you to associate a upper-bound to the validity time interval of a decision. Maybe we should make the checking of time validity a mandatory thing in the xacml engine, meaning that we optionally associate validity intervals with attribute and policy statements, and if they are present, they will always be checked with the evaluation time. So, no need to write any policy rule tests for time validity as it will be done for you automatically and always. -Frank. Polar Humenn wrote: > On Thu, 4 Mar 2004, Frank Siebenlist wrote: > > >>I just came accross the fact that the request's attribute element has an >>optional InstantIssue element to indicate the date and time at which the >>attribute was issued, but you can't seem to specify a duration validity interval. >> >>Any reason for that? > > > All values attributed to resources, subjects, and actions pertinent to > the Access Decision Request should be validated for the request. (Another > reason why the PDP shouldn't supply the "current-time", a serious fault, > IMHO). The XACML Policy does not do validation. The PDP performs access > decisions based on valid information. > > The reason for this approach, is that we did not want XACML to become a > validation engine. The business of checking signatures, validity times, > handling cryptographic computational complexity, is all out of scope, and > that is easily divided and pawned off on some other entity, so XACML will > have to complicate is job with those matters. > > As far as Time goes, I never liked IssueInstant being in the > ReqeustContext. Furthermore, you can't search on it using a > AttributeDesignator, so it's existence is really moot, except, I guess, > for the XPath folks. > > Cheers, > -Polar > > > >>Regards, Frank. >> >>-- >>Frank Siebenlist franks@mcs.anl.gov >>The Globus Alliance - Argonne National Laboratory >> >>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php. >> > > -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]