Hi David and Ludwig, et al,
I have been following this discussion and it seems to simply revolve
around
Policy definitions that Deny access under a given set of conditions,
but will
Permit access if there is that given set of conditions PLUS there is a
BTG
indicator that can be checked and if its value is
"glass-has-been-broken"
(BTG = true), then access is permitted:
(given-conditions = true) AND (BTG = false) then Deny
+ send back BTG as reason for Deny, and indicating
obligations PEP has to tell user reason for denial and
options user has to get access
(given-conditions = true) AND (BTG = true ) then Permit
+ send back BTG indicating obligations PEP must enforce
when in BTG = true state
I agree it wouild be useful to have a profile describing how to
implement
this using standard XACML PolicySets, which, it seems to me can be
done in some fairly straight-forward manners using designated URIs for
AttributeIds and ObligationIds, the semantics of which can be
implemented
by the PIPs and PEPs.
For example, if there is a special AttributeId = "...btg",
and a trusted
Issuer of this attribute, then the Policy can look for it within the
context
of the request.
Similarly, a Deny response could use a profile-specific status-code or
just some designated ObligationId to indicate there are
AttributeAssignments
with AttributeId URIs indicating what the PEP is supposed to do.
Bottom line is I would want to understand what cannot be done w XACML
2.0 with
a guiding profile using Attributes and Obligations, before defining
alternate means, which
might eventually prove to have needlessly added complexity to the specs.
Currently, the XACML 2.0 spec indicates that a PEP should only make
specific decisions
if it understands any Obligations that are returned with the decision,
so it seems to me that
a trusted Attribute with the BTG state plus a set of appropriate
Obligations should be
sufficient for this use case.
Thanks,
Rich
David Chadwick wrote:
Hi
Ludwig
On 26/11/2010 08:32, Ludwig Seitz wrote:
On Thu, 2010-11-25 at 17:05 +0000, David
Chadwick wrote:
Hi Ludwig
The model you have appears to be that each user must BTG himself, and
then he is given the BTG attribute after agreeing to this. But this is
not the model we have, and it is not the model of BTG in general (e.g.
a
fire door in a hotel).
You claim your model represents the model of BTG in general. Can you
support these claims?
Yes in so far as it has been implemented and we have not yet come
across any BTG requirement that it cannot satisfy. So in that respect
it is as general as the HL7 model (which is not a universal standard
either)
In a previous mail Mike Davis seems to suggest your model is different
from HL7's requirements, and currently the requirements from HL7 are as
close as it gets for "a model of BTG in general".
Our model is state based, ie. there is a
BTG state that is initially
false (corresponding to unbroken glass) and can be set to true
(corresponding to broken glass) by a defined class of user in the
policy.
Another class of user (typically a manager) can reset the state to
false
(ie repair the glass).
I see no difference between a BTG state and a BTG attribute. Could you
please explain where you see a difference?
Clearly none if the attribute holds the state!
But in your attribute model you did not say how the attribute value was
set to different values. This was added in our model.
this model is much more general and
flexible since it can be applied to
individuals (as in your case) or to roles (e.g. doctors) or to any
combination of attribute holding subjects.
Furthermore the glass state
can be applied to a single resource or a group of resources. To a
single
action or a group of actions. You can find details in last years ACSAC
conference
I'm all in favor of a flexible BTG model, but from what you present
here
I fail to see how that cannot be done within the current XACML (v3)
core
standard.
This is not the issue. The issue is, can we have a standard defined way
of doing it. You suggest using Advice to signal BTG, so I say we should
have a profile to standardise the contents of the BTG Advice. But I
also request a standard way of doing it in XACMLv2 as well, and Advice
cannot do that.
There is absolutely no requirement for a BTG
attribute to be associated
with a specific subject or resource. What this comes down to, is a
question of attribute management, and that's outside the scope of
XACML.
Actually it is in a twilight world, since you have PIPs which manage
attributes, but you dont describe how they work. So you sort of
acknowledge that attribute management is needed, but then dont say how
to do it. What we are wanting to do, is for a specific type of access
control - BTG - is allow the XACML infrastructure (context handler,
PIPs, obligation service etc) to manage the BTG attribute/state so that
applications dont need to. But in order to do this we need to
standardise more of the protocol between the PEP and the XACML
infrastructure so that BTG can be handled by the infrastructure,
thereby reducing the load on applications.
(note that I think BTG profile should
nevertheless give recommendations
about how to do that).
which is what we tried to do in a general way in the draft profile.
My point remains: You seem to derive the
necessity to make changes to
the core standard from your BTG model. I am not convinced they are
necessary to realize your BTG model.
Clearly no changes are needed to XACML if you dump all the work on the
PEP and the application. This is the status quo today. What we would
like to achieve is that the application independent code can take some
of the burden off the PEP. This is the motivation for the profile.
There is a more important problem though: Before coming up with
solutions for BTG, we need a good definition of what the requirements
for BTG really are. Right now we are starting with a solution and are
trying to make the requirements fit, and that seems like a bad approach
to me.
If you care to read our ACSAC paper you will find a set of requirement
there which were derived from the hospital. So we started with a set of
requirements and derived an application independent way of satisfying
them.
regards
David
/Ludwig
