[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] request's attribute assertion lifetime?
On Thu, 4 Mar 2004, Frank Siebenlist wrote: > It just intrigues me why we have this InstantIssue element of the attribute > defined? What was the use case for that? It was left over from trying to incorportate SAML structures in XACML and we abandoned that effort in favor of our own. I wanted to get rid of IssueInstant, but somewhere I lost or wasn't paying attention. Again, it is a useless attribute, and I believe it should be removed. Cheers, -Polar > > -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]