[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] <xacml><model> Proposal of Post Condition
sorry to take so long to respond to this. Michiharu Kudoh wrote: > 1.1 Definition of post conditions > A process specified in a rule that must be completed in conjunction with > access. forgetting for a moment the syntactic issues with the term 'post condition' itself, i have a fundamental problem with the concept of MUST BE COMPLETED as a result of granting access. this implies that if the action does not occur the access should not be granted. that makes it a precondition, or at the very least, an action that occurs *as part of* the evaluation (e.g. 'confirmation of audit entry prior to issuing grant'). otherwise we get into some very dangerous ground quickly: > While XACML defines the processing rules of the post conditions, the > actual meaning of each post condition differs from application. It > also depends on the configuration of the PEP and/or PDP. which would lead us into this: > 4.2 Mandatory v.s. advisory post conditions XACML does not support > any distinction between mandatory post condition and advisory post > conditions. The meaning of the post condition is determined in each > application. Thus, errors and exceptions of the post conditions are > not defined in XACML. ...which in my mind will hamper interoperability greatly. example (gated security) -------- request access to resource X policy: user only log onto 1 system at a time post-condition: kill other sessions on grant (vendor A) evaluate -> kill access to Y -> if ack, grant; else deny (vendor B) evaluate -> grant -> kill access to Y here we have the situation where a user is only supposed to be on one system at a time (or logged in only once, or only one user per system at a time, as in the case of a write to a record...) and yet we are granting access without actually enforcing this. should be a PRE-condition, right? what's the distinction? do we list all the things that are OK to do after because they are not 'necessary' to granting access? i know that it is a slippery slope, but is there a finite set of operations that we are acceptable 'post conditions'? logging seems to really be the only actual example we have, do we do something specifically for that? does this make sense? on the other hand, this makes sense to me: > Necessary cryptographic/security operations to secure target resource: ...in that a 'grant with stipulation' has a finite evaluation. obviously there a requirement for a concise description of stipulations needed here--something similar to our extension for evaluation methods i would imagine. it seems to me from the meeting that the primary issue here was that SAML provided no such mechanism for response? is that the case? b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC