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] | [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