Minutes F2F Wednesday 29th afternoon

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.