Agenda:
- Erik presents real-world policies
- John update on attribute profiles
- David Button on use cases for BTG
- BTG (continued)
Real-world policies
Erik presents example policies taken from Swedish eHealth record
sharing service
Deny-overrides of
- Policy: valid care relation (does requestor have care
relationship with patient)
- Policy set: organisational entitlement
- Policy: user's entitlements day-to-day (how people work, e.g.,
secretary accessing instead of doctor)
David Chadwick says it's not always clear which overall combining
algorithm you want
e.g., implementing EC Data Protection Directive in XACML:
user must be able to read their own information, so want
permit-overrides, but for other rules want deny-overrides
David Choy asks about good approaches for management of XACML
policies
What if zillions of resources, thousands of users who manage access
to their own documents, policies change all the time
Sometimes old-fashioned RBAC or even ACLs are more appropriate
Erik replies that some concerns, such as legislation, are addressed
better by ABAC policies
These can then be deny-overrides-combined with XACML-encoded
user-defined ACLs to make sure both are satisfied
Hal adds that many scenarios can also be simplified by letting users
update each other's attributes
e.g., veteran wanting his wife to be able to access whatever he can
access
It is important to have a good structure in the policy in order to
add/change rules dynamically.
Some sort of "idioms" or "design patterns" for structuring XACML
policies could help, but currently, we don't have the experience yet
to define such patterns.
Andy remarks that from XACML policy, it is often hard to
reverse-engineer which individual users have access. This is a
common question from customers, mainly for auditing purposes.
Hal says that it would be good to collect valid XACML policies as
examples, in particular some that were designed with care or have
been used for real-world scenarios. Unfortunately, many such
policies are confidential.
Andy adds that it could work in an open-source way.
Update on attribute profiles (John)
Resource attributes for US Export Control (EC-US):
USML
Export Control Classification Number (ECCN)
Technical Assistance Agreement (TAA)
Resource attributes for Intellectual Property Control (IPC):
Type
Data (patent nr, copyright info)
Information Stakeholder (previously called Owner)
Use Restrictions (instead of Designee)
License
Effective Date
Expiration Date
Andy asks how to generalize this to other countries than US, e.g.,
BAFA in Germany (?)
John's involved in TSCP, whcih does international export control.
For now probably best to do is define new profile for every country,
later perhaps do international profile based on insights from
national ones.
Hal asks David Chadwick whether there would be possibility to
standardize number of attributes for data protection. In general, it
is a common concern from users about XACML: great language, but what
attributes do I use? So always open for industry-specific attribute
profiles.
Use cases for BTG
David Button explains use case of BTG where commander can give
access to one document per year to subordinate who has not gone
through full clearance procedures. Another case is emergencies,
e.g., troops getting shot at, who get access to maps that they
normally cannot access.
Jan argues whether this is simply complicated context-sensitive
condition, or whether this is really BTG.
Hal says that there is in general a lot of demand for "dynamic"
attributes that can change value between invocations. But as soon as
there's full workflow involved (e.g., user A needs permission from
user B to break glass), then he would be reluctant to standize these
full flows. We should rather focus on just the access control parts
of the story.
BTG (continued)
Issue we didn't resolve yet is how the state database knows "which"
glass needs to be broken (i.e., which state variable needs to be
set)? We have to get information from main PDP to state database.
David Choy asks how to know whether if I break glass, also glass is
considered broken for Erik's subsequent requests. Hal responds that
that's why you have multiple "glass objects";
Hal mentions that we have to move away from binary states. There are
use cases for non-boolean values, e.g., defcon levels.
Discussion about whether glass objects are pre-defined. They are not
in the sense that the profile would fix them once and for all. The
state database could store as many "glass objects" as you want. But
they are predfined in the main policy/PDP, because it takes into
account only certain glass objects, so these are the only ones whose
states affects the decision.
What is initial policy going to look like? Main PDP will return hint
which glass to break in order to get access.
Jan: two ways to do it
1. Define obligations for telling user about which glass needs to be
broken.
2. PEP has command set to break glass, but tells user simply "do you
want to break the glass". If so, PEP breaks the appropriate glass.
Overall scenario: Evaluate policy once, get denied but told which
state variable to enable to get access. Set the variable, re-submit
query, and get access because variable is set.
What is label of glass object? Is a uri that is used as XACML
AttributeId.
Policy has to specify:
- permit rules that implement which users get access to which
resource after which glass was broken
- deny rules that prevent users from obtaining access if glass was
not broken, containing obligations to be returned as hints to tell
user which glass needs to be broken in order to obtain access
Is AttributeId of glass object static or dynamic? I.e., does policy
specify it as constant value, or does it depend on request?
It is dynamic. For example, each role could have its own glass to
break, but policy would just specify: tell employee to break the
appropriate glass for his role. We don't want to explicitly
enumerate in the policy that employee with role1 has to break
glass1, with role2 has to break glass2, etc. Can use attribute
assignment in obligations to instantiate this.
But does this work at all?
Constructing correct AttributeId of glass object from current
request context using attribute assignments in obligations works, so
this is fine.
But what about rule that encodes that with correct glass broken,
access should be granted? Need an AttributeDesignator for
AttributeId that depends on current request context. We can't do
that with current XACML.
Jan suggests to use XML-structured content element State instead of
dedicated AttributeId, use XPath expression into it to select
appropriate variable within XML structure.
Erik suggests that rule specifies simple AttributeDesignator with
static AttributeId, e.g. some-glass-is-broken. But when value is
determined in request context,
Suppose there is role and purpose, e.g., (doctor, examination).
Request context says role="doctor", purpose="examination".
Voices were raised, chaos emerged, conclusion was that it didn't
work.
=== BREAK ===
Hal: let's go back to original requirements
- First request, access denied, but response tells me which
glass I have to break in order to get access. That should
guarantee that (a) I'm allowed to break that glass (with certain
side-effects such as logs or notified managers) and that (b)
when I do break the glass, I will get access.
- User breaks glass.
- User resubmits access request and is permitted.
David updated swimlanes picture of BTG proposal to have two PEPs and
two PDPs: PEP-R and PDP-R for resource, PEP-S and PDP-S for state
database.
Hal suggests to do BTG in layers. First do the flows. Then do state
manager. Then (optionally) show schemes way how to do carry
information in all flows.
Erik argues that it's meaningless, because dynamic AttributeIds
cannot be done in XACML.
Hal says that it can work if either PIP has interface that allows
you to specify not only AttributeId but also matching function, or
AttributeDesignator returns entire list of values and XACML policy
selects appropriate entry from it.
Erik says that for former, we don't have XACML constructs to invoke
this interface (AttributeDesignator does not take matching function
as argument), and latter is inefficient if list is long.
In step (1), how to make PEP return break-the-glass instructions on
Deny? Jan says it makes more sense in the permit-rule with the
break-the-glass conditions, but then need to return Obligations on
Indeterminate. This currently does not exist.
Erik suggests to emulate the dynamic AttributeIds by introducing a
dedicated function. David Chadwick says that is not needed, because
the substitution is done in PIP. For example, XACML policy would
contain <AttributeDesignator
AttributeId="btg_$role_$purpose"/>. The PDP queries the PIP for
this literal AttributeId, without substituting $role and $purpose,
but adds the current request context in the query in the PIP. The
PIP then is smart enough to parse the request context and the
AttributeId string, substitute the values to obtain, e.g.,
"btg_doctor_consultation", and return the corresponding value. Erik
agrees that that works, so dedicated function is not needed.
There were discussions about whether different steps happen through
User or not. Hal argues that current evolution (OAuth, OpenId) seems
to be in favor of thin/stupid/lightweight clients, so client should
be involved as little as possible.
David asks how btgState in his swimlanes get carried across the
entire picture. Hal suggests to do it in layers: first flows, then
state manager, then scheme(s) to carry information. Everything could
be in same document, but take one step at a time.
Sticky policies in XACML
Was a hot topic at the W3C workshop in Luxemburg, at least three
papers there requiring it.
Hal posted an email to the list, but didn't get much reaction.
http://lists.oasis-open.org/archives/xacml/201103/msg00012.html
Issues for tomorrow
- Distributed combining
- OpenAZ update
- Sticky policies (if time permits, otherwise deferred to
mailing list)
Meeting adjourned.
|