[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes F2F 13/14 March 2007
Minutes of XACML TC Face-to-Face Meeting
Austin, Texas; hosted by IBM Austin Research Lab
DAY 1 - 13 March 2007
I. Role and Administrivia
Attendees
Hal Lockhart
David Lin
Anthony Nadalin
Ron Williams
Argyn Kuketayev
Abbie Barbir
Prateek Mishra
Erik Rissanen
Bill Parducci
David Staggs
Rich Levinson
Proposed agenda reviewed and adjusted
II. Discussion
Refer to XACML 3.0 Issues list at
http://wiki.oasis-open.org/xacml/IssuesList
- ISSUE#32: Exception handling
Thread at:
http://lists.oasis-open.org/archives/xacml/200702/msg00034.html
SUMMARY:
Administrative Policy reduction Cases:
1. Not Applicable => no reduction
2. Permit|Deny => reduce
3. Indeterminate => reduce
If reduction performed, Indeterminate results are carried up (as
Indeterminate)
General consensus is that all Indeterminate results need to be
reduced.
VOTE: APPROVED AS PROPOSED.
DISCUSSION:
Currently: if don't get a trusted path leading to Permit or
Deny, then the policy is dropped.
Proposed solution: 1) reduce as now, following Permit/Deny
results: if normal path reduces, OK - take that; otherwise,
2) Follow paths for Indeterminate (both for admin policies
and access policies). See if "potentially" Permit or Deny.
If reach a trusted policy that way, then Access Policy is
Indeterminate. (could get more complex, and if all Rules in
the Policy are Permit, then would not need to try reduce as
potential Deny).
Potential for Denial of Service (DoS), everything is done
twice at each level. Good news is that if you start from
Trusted Policies and evaluate toward the Access Policy, you
don't run into this problem.
Hal: need to optimize for most common case - one-level
delegation, etc.
Erik: but have to analyze complexity of worst case. Want to
make sure someone can't submit an untrusted policy that
causes indefinite evaluation.
Tony: what about backwards compatibility?
Bill: this is actually closer to what we do now - we bubble
up Indeterminate now if don't get a definite Permit or Deny,
and proposal is that Indeterminate would bubble up in the
Admin Policy case also.
NOTE: Diagrams, etc. in Erik's e-mail description of the
problem are with respect to "new" deny-overrides algs:
propagate Indeterminate rather than "potential deny" and let
PEP decide.
NOTE: paths in graphs of "proposed solution" description are
not PolicySets, but reduction paths. Arrows mean that the
policies were authorized by policy at the end of the arrow.
NOTE: Olav's model includes three "flavors" of Indeterminate:
{potential Permit, or Deny, or N/A}, {potential Permit, or
N/A}, {potential Deny, or N/A}.
- NEW ISSUE#72: Need better specification of where PEP-supplied
policies go
Now a supplied PolicySet would end up being parallel to
existing inner PolicySets, which violates current model. See
related Issue#73.
- NEW ISSUE#73: Can AdminPolicies be in different PolicySet
from Access Policy.
Related to problem of scope of evaluation: want to be able to
do reductions "locally". What are the rules for where
policies are placed in the Admin Policy model? "At which
level in the Admin Policy model does reduction start?"
- ISSUE#50: Maximum Delegation Depth
Brief overview of the issue:
Currently we do have a Boolean on whether delegation allowed at
all. Issue has to do with more complex specification of actual
allowed depth.
Currently, delegation depth in Admin Req can now be specified in
an arbitrarily complex way because it is constrained by the
Condition in the XACML policy. Currently delegation depth is an
Attribute in the Request; Admin Policy may have a Condition
saying {"Deleg depth" = 5} OR {"Deleg depth" = 7}, or something.
If just change delegation depth condition to be an upper bound,
then it is hard for an implementation to tell if it is part of
the Condition.
Bill: Seems like delegation depth might need to be a PEP
control, and not an Administrative control. An administrator
might add a delegation depth, and all of a sudden lots of
policies start being invalid.
Erik: a deleg depth will only affect that admin's own policies.
Erik: If allow variable delegation depth, reduction becomes NP
complete. If reducing from the bottom up, have to backtrack and
attempt another path if delegation depth exceeded. If do
reduction top down, can't do deleg depth.
Hal: why not just do reduction as now, but keep track of depth
and stop if exceeded.
Erik: Depth not known until reduction done.
PROPOSAL: Add new "custom" element to express "maximum depth" as
an integer.
ACTION: Erik to write-up formal proposal based upon integers.
- NEW ISSUE#71: Treat different Subjects with same
SubjectCategory as different entities.
Currently, XACML 2.0 does not treat different
SubjectCategories as different entities; all Attributes are
lumped together as if they were one entity.
Anne: presented limit-scope:all and limit-scope:atLeastOne from
WS-XACML specification.
Erik: this would require the arguments to the limit-scope
functions to be treated as strings that are passed to the
function itself, which would evaluate them using XACML
semantics. e.g. Enclose all the arguments in an <AttributeValue>
with some datatype - could be "string", where semantics say
of functions say "evaluate arguments as XACML expressions in
specified scope".
Argyn: this requires Requests to be in XML format. Also
requires support for XPath.
Anne: Yes to XML format. We could add another form of the
limit-scope functions in which the first argument is an
Attributes category, and all the remaining arguments are
Attribute values from within one instance of that Attributes
category. e.g.: ...:limit-scope:designator:atLeastOne takes
AttributeDesignator arguments, and
...:limit-scope:selector:atLeastOne takes AttributeSelector
(XPath) arguments.
Tony: so :atLeastOne returns false if there is no element
that is selected by the XPath expression?
Anne: right. And for :all, we need to specify whether it
returns "true" or "false" if there are no elements that
satisfy the XPath expression.
Erik: could do it with higher-order functions. XACML 2.0
does not allow bags-of-bags, so would need to relax that, and
would need to define a lambda expression syntax.
Erik: MultipleCondition format
(http://lists.oasis-open.org/archives/xacml/200703/msg00010.html)
solves the same problem as limit-scope:all in the
AttributeDesignator form. Example:
<Condition>
<MultipleCondition FunctionId="string-equal"
Category="intermediate-subject"
AttributeId="role"
DataType="string">
<AttributeValue>manager</AttributeValue>
</MultipleCondition>
</Condition>
Means all intermediate-subject Attributes groups must have
role="manager" with DataType="string".
Would be easy to generalize to "atLeastOne"
NO RESOLUTION
- ISSUE #68: Backwards compatibility of generalized Target
Erik noted that this is dependent upon "multiple conditions",
so this was tabled until ISSUE#71 is resolved.
- WS-XACML Presentation
Anne presented the WS-XACML Profile. She will be reworking
the slide presentation for distribution (available at
http://research.sun.com/projects/xacml)
ACTION: Anne to describe on mailing list the separate top-level
PolicySet
possibility for grouping WS-XACML assertion requirements for
guidance and review. Not appropriate for normative
specification.
DISCUSSION:
ISSUE#56 add Preference Attribute; extend XACML Expression to
create a new flavor of <Apply>
ISSUE#57 XPath expressions may all need to refer to leaf nodes
ISSUE#76 with limit-scope functions, it is probably not
possible to match predicates because they can select
different sub-trees of a document. limit-scope may be useful
for general XACML policies, however. Might also be possible
to define handling of subsets if Capabilities can only
specify "all" elements in a subtree will satisfy
requirements, but that any subset may be required; requires
more thought.
ISSUE#76 include <AttributeDescriptor> form of the
limit-scope functions; don't force use of XPath.
ACTION: Anne to describe on mailing list how Vocabulary elements
are used more clearly.
ACTION: Anne: justify "must-not-be-present" function better -
example
ACTION: Anne: in WS-XACML profile, make sure fact that vocabulary
domains is known is being utilized: any vocabulary element
that is not explicitly constrained either has no constraints
or is not allowed.
- Issue #61 XACMLAuthzAssertions in access control Policies
The TC discussed the inability of XACML policy Attributes to
be extracted independently; particularly via normative
language.
Rich asked if usage guidance can be posted to the list. Anne
offered that some non-normative suggestions can be created,
but that it should be of limited scope since this is
implementation specific.
ACTION: Anne to post description of possible approaches to
mailing list.
- CONFORMANCE TEST
Argyn initiated discussion on Conformance testing in XACML
v3.0.
Conversion of existing conformance tests: we will translate
copies of 2.0 tests to 3.0. Testing 2.0 requests input to 3.0
policies or 3.0 requests input to 2.0 policies handled by 3.0
PDP is not committed, but would be nice.
NOTE: We don't have version indications in Request context: but
can determine from the namespace element.
ACTION: ?? to query the XACML mailing lists to see how people are
using XPath expressions, and we can try to develop
translation methods for the commonly used formats.
Erik: we have 3.0 tests that we could contribute.
Argyn: where do we store conformance tests? It is more
convenient to track changes with a source control system.
Hal: some TCs are using CVS.
ACTION: Hal to ask Mary McRae what OASIS can support.
- ISSUE#9 and ISSUE#68: Conformance led into a discussion of
backward compatibility and migration from v2.0 to v3.0
automatically. It is generally believed that
<ResourceContent> in a Request can be mapped to <Attributes
Categories=""> except in case of certain XPath expressions
(e.g. element[2]).
GENERAL CONSENSUS is that v2.0 Conformance Tests will be modified to
support v3.0 and supplemented to address new functionality.
Hal: we can require that 3.0 implementations support 2.0
policies and requests, but not dictate how. Sites might convert
all their policies once, they could have a pre-processor, or
could actually support two schemas at once in the PDP itself.
Erik: there is the issue of XPath expressions in 3.0 policies
that will resolve to different targets in 2.0 Request Contexts.
Argyn: if a policy is converted from 2.0 to 3.0 format, it may
contain XPath expressions that were originally written to 2.0
Requests.
Erik: our implementation does the translations of policies and
requests, but don't deal with XPath expressions. Won't work
with 2.0 policy that gets a 3.0 request.
Anne: possible to specify that all references to
//Request/Resource/ResourceContent/ are converted to
//Request/Attributes[Category="Resource"]/Content/
Erik: example of problem is if the XPath expression points to
element[2].
Hal: do we really need to translate Request Context?
Erik: except for XPath expressions, it is trivial.
PROPOSAL: 3.0 PDPs MUST support 2.0 policies and 2.0 requests in
some way that we do not specify. Exception: XPath expressions
will be on a best-effort basis (usually need to be translated by
hand). Supporting requests requires on-the-fly conversion, but
policies MAY be converted once, using a pre-processor, by
supporting two schemas at once in the PDP, or in any other way
that satisfies the requirements.
PROPOSAL APPROVED UNANIMOUSLY
- ISSUE#68 Backwards compatibility of generalized Target
The general consensus is to allow the more generalized form of the
<ConjunctiveMatch> syntax. This will preserve v2.0 compatibility in
the Target.
In XACML 2.0:
Subjects/Resources: conjunctive
Subject/Subject: disjunctive
SubjectMatch/SubjectMatch: conjunctive
these could be different SubjectCategories
In XACML 3.0,
Each SubjectCategory will be a different "Subject", and all
<ConjunctiveMatch> elements must refer to same <Attributes
Category="X">, so can't intermix equivalent of different
SubjectCategory Attributes.
MODULO ISSUE#71 Treating different subject categories as
different entities
PROPOSAL: within a ConjunctiveMatch, different Match elements
can reference different Attributes Category values.
PROPOSAL APPROVED.
- EXIT CRITERIA FOR XACML 3.0
XACML 3.0 implementations: we will need 3 conforming
implementations; the definition of "conforming
implementations" is being tightened up.
XACML 3.0 scope: when will set of issues not to be addressed be
settled. Answer: no set rule.
- PEP/PDP
Hal reviewed his posting re: Policy provisioning.
Hal: Assume PAP knows where PDPs are and what policies each
needs to have; not all PDPs need all policies. Whole
motivation for creating an XACML profile is because
XACML-related knowledge is needed to know which policies each
PDP needs; just a general "push everything" doesn't require
any fancy protocol and requires no special XACML knowledge.
PAP knows when policies change, so knows when new policies
need to be pushed to PDPs. What is needed for a provisioning
protocol:
- Minimal requirement is: "Unsolicited push" from PAP to
PDP(s).
- SPML batch package operation to push policies that are
needed.
- Query from PAP to PDP: what policies do you have?
- Query from PDP to PAP: sync me up (e.g. when PDP starts up
or restarts after being down), possibly establish channel
for PAP to push new policies later; "sync me up" might
include list of policies the PDP already has, or might ask
for "which should I have", then PDP goes back and asks for
the one it doesn't have.
- Incremental step further: PAP could also provide a batch of
policies and a time, saying "this batch of policies must be
atomically loaded at given time".
David: why is XACMLPolicyQuery not suitable?
Hal: it was really designed primarily for retrieving
referenced policies by PolicyId
Argyn: proposed PDP-local PAP and remote PAP
meeting adjourned for the day
F2F DAY 2 - 14 March 2007
I. Administrivia
Agenda reviewed and adjusted.
II. Discussions
- SAML Profile
Anne reviewed the SAML Profile
NEW ISSUE#74 specify how to use SAML metadata.
- ISSUE#54 Number of policies required by administrative policy
delegation
The VHA model currently uses a database attribute to hold a
list (group) of all subjects who are authorized to do
something. In order to delegate, the modifier of the
database entry must have authorization to modify that
database entry. David wanted to know if this was a
reasonable approach, or if Policy Admin should be used
instead, even though it would lead to a large number of
policies.
Erik: If it is working, don't change it. Big gain of 3.0
model is allowing grouping of resources under the same
policy. For example, can create two delegation policies for
two owners of different resources, and they can delegate it
further. They can delegate to a single authority that
aggregates the two policies. Useful in federations, such as
roles. A complete solution must contain attribute
administration as well as policy administration.
Hal: VHA scheme would not work well for GRID scheme where
they want to pass policies on the fly; no time or place to
update an attribute repository. VHA environment has large
number of users with potentially the same situation, so
amenable to the attribute-style solution. One
strength/characteristic of XACML is that everything in the
policy is self-contained; authorization decision is made
based solely on Request and Policy[Set]. When assigning
Subject Attributes, they should typically be something that
would be understandable to the president of the company -
they should be constructs that make sense in your
organization; should not be categories created specifically
for access control. XACML Admin Policy model is like a bank
teller, who can take money out of Hal's account when
requested by Hal and given to Hal, but not on the teller's
own authority.
General consensus: there are various ways to implement
delegation, and the current VHA approach may well be the best
approach for their situation.
III. Review of issues not yet closed
- ISSUE#3 Generalized Attribute Categories
Change from Open to Pending Review, since in most recent
Admin Policy draft.
- ISSUE#5. Policy statements in the request context
Pending Review: should clarify where Admin Policies should be
in the same PolicySet, but that is a new issue #73.
- ISSUE#72 [New issue] Where should passed-in Admin Policies be
inserted?
Erik suggests the base Policies should be constructed with
Admin Policies in mind, so it should be clear where they are
inserted.
- ISSUE#4 PPD references in policies
Change to CLOSED for lack of active champion
- ISSUE#8 Alternate Owner-Policy-Statement to determine sentinel
CLOSED for lack of active champion
- ISSUE#12 General obligations
Bill will talk on this later
- ISSUE#13 What are my permissions?
Erik's student looked at it, and found some cases that could
be handled
Change to CLOSED for lack of proposal and no impact on
current schema
- ISSUE#22 Right to revoke
Erik: has a research paper he is working on, but hasn't
finished writing up. Recommends deferring. As interim
measure, people have to do their own revocation. Hasn't
tried out his model, and wants to make sure it works in
practice.
Example: two resource owners A and B have delegated to User
C; C creates a policy that contains both Resource A and
Resource B. If Owner B revokes the policy, it affects access
via C to Resource A. So need to look at who revoked it, how
the resource is being used.
Hal: concerned about ignorance issue - person doing reduction
never sees the revoke (not an issue in the repository case,
where you can just remove it from the repository).
Anne: One use case for revoking another's policies are where
the other issuer has left the company.
Erik: not sure about how far down revocation should be
allowed; problem becomes NP-complete.
Erik: is it OK for the PDP to do revocation?
General agreement: yes. We are not specifying anything about
how revocation is done.
Changed to CLOSED for 3.0 for lack of complete proposal.
- ISSUE#23 Access permitted
Erik: doesn't work now because worded against old Subject,
Resource, etc. If rephrased in the wrong way, it can become
NP complete. Hal had agreed to provide a new proposal. The
wrong way is to allow adding new information while you keep
old information in the request; OK to replace old subject
with new subject. But if just add a subject that was not
there originally, problem becomes NP complete. Reference:
terse e-mail on 2/22/07 from Erik (Message#56).
Change to OPEN; action item for Hal to provide proposal.
- ISSUE#24 Mixed administrative/access target
Change from PENDING REVIEW to CLOSED. Text accepted.
- ISSUE#25 Nested policy sets and enforcement of delegation
constraints
Change from PENDING REVIEW to CLOSED. Text accepted.
- ISSUE#27 The issuer of the PDP policy set
Change from PENDING REVIEW to CLOSED. Text accepted.
- ISSUE#31 Passing arbitrary sets of Attributes in the request
Hal: the existing profile can serve as a checklist for the
types of information that need to be provided.
Change from PENDING REVIEW to CLOSED. Text accepted.
- ISSUE#32 Exception handling
Change from OPEN to PENDING. This is the problem we
discussed on Tuesday. Erik will provide text for review.
- ISSUE#33. How to match any delegate
Proposal pending new core schema. Current status is that
current schema specifies a solution for this. If you want to
match any delegate you don't write anything on the delegate.
Change to PENDING REVIEW
- ISSUE#34. Draft 10 has a circular import in the schemas
Change to PENDING REVIEW. Fix in current draft.
- ISSUE#36. PDP metadata
Bill: would be useful for PDP to indicate whether it has a
bias for permit or deny.
Hal: Also implied top-level combining algorithm, and whether
historic or current Attributes are used.
Hal: recommends providing some XML syntax and some suggested
publication methods. Need to provide a metadata schema.
Refer to SAML's 2.0 metadata spec. We could steal their
approach.
ACTION: Bill to provide proposal. Still OPEN
- ISSUE#40. Change ResourceContent
One thing still needs to be changed: remove content-uri.
Leave PENDING, otherwise, current draft OK.
- ISSUE#41. Flag to force evaluation of all applicable policies
Change from OPEN to CLOSED due to technical issues.
- ISSUE#42. SAML Profile: Matching of holder identity against the
request context
Change from PENDING REVIEW to CLOSED. Text accepted.
- ISSUE#43. SAML profile: Inheritance between additional attributes
Change from PENDING REVIEW to CLOSED. Text accepted.
- ISSUE#44. SAML profile: Do we add attributes to the access
request?
Change from PENDING REVIEW to CLOSED. Text accepted.
- ISSUE#45. In the SAML profile: Translation of saml:Subject?
Leave as PENDING REVIEW. Draft came out too recently.
- ISSUE#46. SAML profile: multiple holders of attributes
Currently yes.
Change from OPEN to CLOSED. Text accepted.
- ISSUE#49. Delegation with attribute categories
Change from PENDING REVIEW to CLOSED. Text accepted.
- ISSUE#50. Maxdepth with attribute categories
Conceptual agreement on creating a new element.
Change from OPEN to PENDING.
- ISSUE#51. Reduction of deny with attribute categories
Change from PENDING REVIEW to CLOSED. Text accepted.
- ISSUE#52. Indirect delegates with attribute categories
Change from PENDING to CLOSED.
- ISSUE#53. Computational complexity of delegation
Change from OPEN to CLOSED.
- ISSUE#54. Number of policies required by administrative policy
delegation
Erik's specification addresses administration of policies,
not of Attributes.
ACTION Erik to add note about alternative ways to do delegation.
Change to PENDING
- ISSUE#55. WS-XACML: Address policy references in a Requirements
element containing a PolicySet
Still PENDING. Will re-use same element defined for SAML
Profile Policy references.
- ISSUE#56. WS-XACML: Add optional "Preference" XML attribute to
Apply element
Resolution: WS-XACML will define a new type of "Apply"
derived from XACML Expression for constraints, and add such
an XML attribute.
PENDING
- ISSUE#57. WS-XACML: Restrictions on XPath expression to support
matching Attribute references
Anne is still reading references.
PENDING REVIEW
- ISSUE#58. WS-XACML: Handle P3P 1.0
POLICY/STATEMENT/NON-IDENTIFIABLE in an XACMLPrivacyAssertion
ACTION: Anne to update description to remove my old Action
items.
OPEN
- ISSUE#59. WS-XACML: Allow restricted regular expression
functions in XACMLAssertion
We will allow. Anne needs to write up.
PENDING
- ISSUE#60. WS-XACML: Remove "XACML Authorization Token" and
"Conveying XACML Attributes in a SOAP Message"?
Change from PENDING REVIEW to CLOSED. Text accepted from
current SAML Profile draft.
- ISSUE#61. WS-XACML: How are the contents of
XACMLAuthzAssertions represented in the base XACML Policies
ACTION: Anne will post description of one way to the list, and
might be included as non-normative example in the SAML Profile
itself.
DEFERRED until Rich can call in.
- ISSUE#62. Policy provisioning interface
Still OPEN. Hal will do skeleton proposal for two protocols,
one PAP-initiated, one PDP-initiated.
- ISSUE#63. Generalizaton of multiple resources
Defer until after lunch.
- ISSUE#64. Treatment of administrative deny
Still PENDING.
- ISSUE#66. Missing attributes may be underspecified
Defer for Rich and Prateek.
- ISSUE#67. Add XPath 2.0 support
Already support specification of XPath version.
ACTION: Daniel to submit proposal for specifying settings.
- ISSUE#68. Backwards compatiblity of generalized Target
Allow more general form.
PENDING (see discussion notes earlier)
- ISSUE#69. Incorrect URL in
access_control-xacml-2.0-context-schema-os.xsd schema file
PENDING - fix it and approve Errata
ACTION: Argyn to send out schema with corrected URL.
- ISSUE#70. SAML Profile: IDs for policies in XACMLPolicyStatementType
ACTION: Anne to check with Seth, otherwise seems OK to
require Policy[Set]Reference value to match Policy[Set]Id in
the referenced policy.
- ISSUE#71. Treating different subject categories as different
entities
OPEN.
- ISSUE#72. Where should passed in (SAML profile) policies be inserted
OPEN.
- ISSUE#73. At which level in a nested policy set does reduction
start?
OPEN.
- ISSUE#74. Add SAML metadata to the SAML Profile
OPEN.
IV. Call with Rich Levinson and Prateek Mishra
A. ISSUE#61 WS-XACML: How are the contents of
XACMLAuthzAssertions represented in the base XACML Policies
3 separate sub-issues:
a) Whether we are talking about XACML Policies or individual
sequence of <Apply> elements
b) How to flag individual constraints
c) Querying for policies from enterprise
d) Collecting policies relevant to a particular service
If central admin does policy, it all goes into enterprise
repository, so how does Web Service pull out what goes into
its WSDL.
In order to get a policy associated with a specific resource, Web
Server would need to query for all policies associated with that
resource.
Could construct policies in a separate PolicySet.
Hal: is there still some open requirement?
Rich: need to absorb all the information and see where it
needs to be pushed further, if it does.
Rich: How to front-end the requirements of the net.
WS-Security Requirements and set of Assertions populated
there - might come out of same repository, but he's not
suggesting that now. OK to move on from Issue#61 now.
CLOSE Issue#61 and open new issues as they arise.
B. PDP provisioning protocol
http://lists.oasis-open.org/archives/xacml/200702/msg00061.html
Hal described the basic protocol requirements we worked out
yesterday.
Prateek says they would be interested in contributing.
Specify indices on which push and pull are based.
Hal: assumption is that PAP knows which PDPs are supposed to
get which policies and they are all indexed by Policy[Set]Id.
C. PEP/PDP issues: closely coupled PEP/PDP
http://lists.oasis-open.org/archives/xacml/200702/msg00060.html
Hal: BEA and IBM provide this, but no XACML-specific
standardization around it. Can't do it in a very generic way
- needs to be for a very specific environment, such as Java
or CORBA. [Prateek agrees] Would some of the J2EE-defined
things be sufficient, or does it need to be XACML-specific?
Prateek: if enterprise invests in an XACML infrastructure,
enterprise would like all their applications to be able to
interact with the authz engine with some API. By use of
containers, this can be pushed out for coarse-grained authz,
but need to point to some API in a direct way. Not to
suggest that current J2EE approaches are inadequate, but a
specific API would enhance value of XACML.
Hal: BEA has contributed some of their SPIs to JSRs. They
use these to invoke XACML from containers and applications.
Not XACML-specific. BEA could explore whether they would be
willing to contribute some of their SPIs.
Ron: JACC use-models are limited. Specification provides a
hole in the container through which you can get at the
necessary information. Still have to implement the
mechanism. Some people think advantage of XACML is can
implement not just the JACC-specified web policies, etc., but
can provide fully expressive policies.
Hal: BEA supports JACC because it is a standard, but they
encourage use of their SPIs, which can support more
expressive policies. Let's identify specifically what is
insufficient about JACC (JSR#115). Then decide what to do
about it.
Prateek: identify some of the patterns and flows that are
hard to fit into JACC. A "generic Java environment" is a
good starting point. He and Rich will take action item to
identify these.
NEW ISSUE#75: need to define interface for a closely-coupled
PEP and PDP.
D. PEP/PDP issues: how do you know what inputs the policies refer
to?
http://lists.oasis-open.org/archives/xacml/200702/msg00059.html
Hal: it is really the PEP and PAP that care what Attributes
are needed to satisfy policies. The WS-XACML "Vocabulary"
mechanism might be sufficient: advertise per Web Service an
identifier associated with a set of Attributes and their
semantics.
Prateek: that is a good starting point. Need to work through
an appropriate definition for it. Rather than Vocabulary
involved with a Web Service, the Vocabulary involved with a
PEP.
Hal: or is it more valuable to know this on a Web Service
basis. Support of a Service by particular PEPs is hidden
from the Web Service interface. Don't you want to know on a
Service basis?
Prateek: brings up which services are managed by a PEP.
Hal: but if you know which services, do you even care about
which PEP?
Prateek: issue is of deployment-level information. If I
purchase or send out RFP for a content repository that will
support some PEP, then need to be able to say something about
what the PEPs require. Need way to describe expected set of
queries that might arise from a PEP; otherwise hard to
implement a plug-and-play environment.
Hal: that seems like more a runtime administration issue.
Prateek: another scenario is that applications are delivered
with embedded PEPs. Want to know what kinds of queries will
be generated from them. Want to tell application developers
to use a certain request/response language. How would you
characterize your expectations of those PEPs?
Hal: might conform to XACML SAML message format.
Prateek: need to know also what Attributes they would carry.
Ron: application should provide policies "out of the box"
that are suitable for that application. Might need some
hooking up for retrieving the specific Attributes required.
Hal: could define meta-data to say "this set of roles is in
use", which might be useful for a policy editor tool, but who
else needs to know that?
Ron: a product already defines how it operates and the
semantics of its access control. Integration into the
enterprise is at the level of mapping roles onto the
enterprise users.
Prateek: a few use-case scenarios on the list would be
helpful. Big picture scenario is where an enterprise is
acquiring applications with embedded PEPs, and would like to
understand what could possibly be obtained in the queries
that would come from the PEPs. Need to know which Attributes
the PEP will provide in its Requests, and which will need to
be retrieved from elsewhere.
Hal: could provide a schema for describing all Attributes
that might be required and where they are obtained.
Prateek: that might be all that is required. Again a few
concrete examples might be helpful. He will provide such
examples and example descriptor that characterizes what a PEP
proposes to emit and accept back (which Obligations).
Related to some of the vocabulary discussion we had, but
needs to be clarified with example.
ACTION: Prateek to generate examples
E. Resource Attributes
http://lists.oasis-open.org/archives/xacml/200702/msg00059.html (4)
Hal: experience has been that every enterprise defines these
differently. Not sure how much could be standardized.
Prateek: mostly interested in finding some formats for
Resource meta-data. Formats that would indicate ownership of
the resource, other aspects of the resource. Might be
difficult to make much progress on standardizing this.
Hal: some vertical industry groups are defining such
metadata, such as the geo-spatial people (they even added
functions, not just Attributes, since their "resources" might
overlap each other).
Prateek: so may not have a general framework.
Hal: perhaps Seth could point us at some of the groups that
have been defining AttributeIds for their problem sets.
Prateek should contact Seth directly and ask for links to
industry groups that may have defined such things.
F. Referencing policies by PolicyId
http://lists.oasis-open.org/archives/xacml/200702/msg00062.html
Hal: PDP must have a mechanism for retrieving policy by Id.
Prateek: no need to go further so long as PDP knows how to
retrieve? Even with multiple PAPs operating on a policy
repository, is there no additional information needed?
Hal: two general cases. 1) PDP has no policy storage at all
between one evaluation and the next; makes a network call to
the PAP for each decision, 2) PDP has policies lying around
and uses them for each decision.
Hal: being able to get policy by Id is just part of the
general requirement that you have to be able to get them by
situation and by Id.
Prateek: so maybe don't need anything beyond.
Hal: so an Oracle database may be used to store policies, or
DB2, etc.
V. A Chat on Obligations
Bill presented current status of enhanced Obligations.
Erik presented an alternative that his group developed.
Bill and Erik have had some conversations about this. Erik
had a student (Jafar) working on it.
Basic idea: a completely unbounded problem [Hal: "an
open-ended kludge"] Biggest problem is what to do when you
have a large bag of Obligations and need to reduce them to
something that the PEP can fulfill. Combinations possible
for interactions become too complex.
Bill had suggested hierarchical approach similar to
Michiharu's category approach (on WIKI). Would also need to
have hierarchy among the categories themselves.
Still have to overcome problem of resolving conflict. Bill
migrated toward thinking this should be handled in the
Context. In conjunction with Michiharu, decided terms needed
to be better defined.
Need to decide whether context is place to handle this, and
whether we have an approach that will work with this
unbounded problem.
Spec says: PEP must not allow access if doesn't understand or
can't fulfill an Obligation passed back with a decision. We
don't have multiple flavors (ignorable, mandatory).
Hal: Michiharu's presentation summary: for bag of
Obligations, might want to do all, pick some, etc.
Bill: one could say encrypt Blowfish, another encrypt DES.
Combining mechanism could be "pick one". Hard part is where
one Obligation says "stand", the other says "sit", and they
have the same priority.
Erik: similar to Permit/Deny conflicts, except that number of
separate Obligation identities is unbounded.
Hal: would need to have a matrix to show which Obligations
override others where there is any possibility of conflict.
Bill: proposed precedence hierarchy for categories. Side
benefit of the matrix is advertising which Obligations need
to be understood.
Erik: alternative solution (URI-combiner).
Obligation-combining-algorithms via callbacks to the PDP
Jafar's proposal (roughly):
<PolicySet> can define
<ObligationCombiningAlgS>
<CombiningAlg id="overrides-combalg">
e.g. If person has both normal and emergency
access, should use the normal access to avoid
unnecessary auditing related to access allowed
only for emergencies
Example: ObligId="Normal", ObligId="heavy-audit"
<CombAlg id="overrides-combalg">
<Policy>
<Obligs > f([a1],[b11,b12]...], WS),ObligPS</Obligs>
</CombiningAlg>
</ObligationCombiningAlgs>
Erik: Output of one algorithm is passed to the next.
Requires
implementation in code.
Erik: Michiharu had defined five basic categories of
obligations
(e.g. atomic: choose only one; ). Bill introduced hierarchy:
precedence of different categories, in case where they are
exclusive. Erik: The five categories are five different
kinds
of combining algorithms. We could define standard
categories.
5 Categories: atomic, data processing, cycling, [see WIKI]
Hal: we've proposed defining some standard Obligations, but
haven't gotten proposals.
W3C Workshop on future of Web Services; one paper was from
some
financial industry organization (FSTC) that recommended
establish policy languages for various functional and
non-functional services such as QoS, ...
Rich: was thinking of using Obligations to return privacy
data.
Don't know if that is feasible or not. [we asked him to post
description to list so we can think about it]
VI. Adjournment
The meeting adjourned at 4pm.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]