[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] request's attribute assertion lifetime?
It just intrigues me why we have this InstantIssue element of the attribute defined? What was the use case for that? -Frank. Frank Siebenlist wrote: > 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]