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

Subject: Minutes F2F Wednesday 29th afternoon

  • 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):
Export Control Classification Number (ECCN)
Technical Assistance Agreement (TAA)

Resource attributes for Intellectual Property Control (IPC):
Data (patent nr, copyright info)
Information Stakeholder (previously called Owner)
Use Restrictions (instead of Designee)
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
  1. 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.
  2. User breaks glass.
  3. 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.

Issues for tomorrow

  • Distributed combining
  • OpenAZ update
  • Sticky policies (if time permits, otherwise deferred to mailing list)
Meeting adjourned.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]