XACML Wiki
Issues List
Below are the current issues for the XACML TC
Closed issues have been moved here: ClosedIssues
The status of each item is indicated with the following options:
OPEN No agreement on resolution.
PENDING Resolution has been reached, but is not reflected in the latest draft.
PENDING REVIEW Latest draft has been recently been updated to reflect resolution.
CLOSED Issue resolution is reflected in current draft or issue was dropped.
DEFERRED Issue is inactive but will be considered at a specific future time.
The target of the issue is indicated in the title as follows:
ADMIN Administrative Policy Profile (including administrative policy topics that affect 3.0 Core)
CORE XACML 3.0 Core
ERRATA XACML 2.0 Core errata
PROVISIONING Policy provisioning
SAML SAML 2.0 profile of XACML Version 2
WS-XACML Web Services Profile of XACML (WS-XACML)
12. CORE:More general conclusions
It has been proposed that the XACML language should be generalized to allow more complex decisions than yes/no. This could for instance mean that a rule which specifies encrypted access would override or be overridden by a rule which specifies unencrypted access, according to rules specified in the policy. There has also been discussion about imperative sequences as conclusions. Backwards compatibility with obligations is also an issue in this context.
The outstanding Use Cases are being addressed via modification of the current Obligation mechanism. http://wiki.oasis-open.org/xacml/DiscussionOnObligations
Erik and Bill are working on a proposal as of 10 May 2007.
Status: OPEN
Champion: Bill
36. PDP metadata
Should PDP metadata be made available in some form? Currently the following meta data has been identified: Attribute timing. Top level combining algorithm.
Action: Bill to provide a proposal (pending the outcome of #12).
A "placeholder" list has been created http://wiki.oasis-open.org/xacml/MetaData#preview to capture potential meta data of interest.
Status: OPEN
Champion: Bill
62. PROVISIONING:Policy provisioning interface
We have agreed (Issue#39) that the SAML Profile XACMLPolicyQuery will not attempt to provide a robust policy provisioning interface. The alternative proposal is that a separate policy provision interface be provided, possibly using SPML. Do we want such an interface?
Proposal outline at http://lists.oasis-open.org/archives/xacml/200702/msg00061.html. Discussion from March 2007 F2F in Minutes at end of first day at http://lists.oasis-open.org/archives/xacml/200703/msg00069.html
XACML Policy Distribution
New definition: Policy Cohort
A Policy Cohort is a set of policies (and/or policy sets) which are intended to be in force at a given time. Under XACML 3.0, a Policy Cohort may include both Administrative and Access Policies. However a Policy Cohort does not include just in time policies which are delivered with a decision request and in force only for the duration of that request. A Policy Cohort is typically tested as a unit and distributed as a unit.
A Policy Cohort has a name, which is a URI and it has members, which are zero or more policies or policy sets.
Assumptions
There is a Policy Administration Point (PAP) which holds all the policies for some domain. There are a number of Policy Decision Points (PDP) which retain in some local (typically non-volatile) storage one or more Policy Cohorts which are currently in effect or scheduled to be in effect in the future. A PAP will typically serve a number of PDPs. Conceivably a PDP may get its policies from several PAPs, however I am not aware of a motive for this usecase.
Multiple redundant PAPs may be deployed to improve availability. The means by which as PDP selects the PAP to obtain Policy Cohorts from will not be specified in the profile. Multiple PAPs or sets of PAPs may also be deployed to serve distinct sets of PDPs.
Each PAP must maintain configuration information assigning one of more Policy Cohorts to each PDP. If no Policy Cohorts have been assigned to a PDP, that PDP can not make access control decisions. For each mapping of a Cohort to a PDP, the PAP may maintain an effective date/time and an expiration date/time. If the expiration date/time is unspecified, the Cohort should go into effect immediately. If the expiration date/time is unspecified the Cohort is valid indefinitely.
This protocol is concerned only with the interaction between one PDP and one PAP. It is assumed that the PAP knows what Policy Cohorts should be in effect at different times at given PDP by some unspecified means. In a real deployment, this could be done in a number of ways. For example:
1. The UI which allows admins to creates policies also provides a mechanism which allows the admin to specify what PDPs should get what Cohorts at what times. This could be done individually or by grouping PDPs in some way.
2. The admin could be allowed to define some templates to apply to targets in policies in order to determine which PDPs get them. For example, each PDP might handle decisions with resource names that contained certain dns names. Say PDP1 gets policies pertaining to *.factory.example.com and PDP2 gets policies pertaining to *.marketing.example.com.
3. Policy identifiers could be chosen to indicate something about which PDP gets a given policy.
It is also possible that a PDP might have multiple distinct Policy Cohort which are in effect at the same time. In this case, the Cohort to evaluated must be determined for each policy decision by some means unspecified by the Profile. Typically the name of the Cohort would be specified implicitly or explicitly by the PEP.
It is assumed that each PDP has a unique identifier which the PAP knows in advance.
The protocol should make it easy to recover from failures of either participant or the communications link. Also in most cases work done prior to a failure should not have to be repeated. The protocol should make it possible for the PDP to determine that it has a complete and consistent set of policies.
It should be possible to stage Cohorts to go into effect at a future date.
The policies comprising a Cohort may not fit in a single message. However, it is assumed that no policy is so large that it can not be transmitted in a single message. In other words, it will never be necessary to split up a policy. Because it is likely that Policy Cohorts may often differ from each other by the addition or change of a few policies, it should only be necessary to transmit policies which the PDP does not already have.
All XACML Policies and Policy Sets contain an identifier. Different policies can contain the same identifier, but they will have different versions. The combination of Policy Identifier and version is assumed to be unique. For the purposes of this discussion the Id & version pair are called a Policy Id.
Although this Profile is intended for the distribution of XACML policies, it could be used with any sort of access control policies which can be carried in the envelope (i.e. represented in XML) and that have a unique identifier for each policy.
Two different protocols are defined, a push protocol (controlled by the PAP) and a pull protocol (controlled by the PDP). Both protocols have different advantages and disadvantages. It is expected that each will be used in different environments.
ISSUE: Would it be sufficient to use PAOS (reverse HTTP) with the push protocol instead of the pull protocol? It is not clear how practical the use of PAOS is when no data is transmitted for long periods of time. Of course, this objection could be met by defining some kind of heartbeat messages which would also allow for the determination of whether the parties are still functioning. However, this starts to move the scheme in the direction of a general purpose management protocol.
- Push Protocol
[This needs to be either dropped or updated to incorporate the notion of Cohorts.]
1 Req. (Optional) PDP -> PAP request policy update.
This message will be useful in cases such as a PDP first starting up.
2. PAP -> PDP request current policy list
This can be sent in response to an update request or as an unsolicited message. A PAP might initiate the request because an Administrator has updated the policies.
2. PDP -> PAP response with list of Policy Ids currently held by the PDP. Optionally the PDP can specify a maximum message size for policy updates.
PAP compares the policies held with the list of policies the PDP should hold.
3. PAP -> PDP Policy update batch.
The batch may begin with an optional effective date/time for the set of policies in the batch.
The batch contains two kinds of items:
A. Delete policy – specifies the Policy Id of a Policy to delete B. Add policy – contains Policy or Policy Set to add
(Batch mechanism TBD. Could use SPML batch function or WS-RM sequence.)
Each message in batch should be acknowledged. PDP should implement atomic update. No action should be taken until complete batch is received. Once batch is complete, the effective date/time should be checked. If it is missing or in the past, the update should be done immediately. Otherwise the update should be delayed until the effective date/time is reached.
In either case, when the update is performed, policy evaluation should cease. All deletes and adds should be applied. Then evaluation should resume.
- Pull Protocol
1. PDP -> PAP Request list of available Cohorts for specified PDP (default: this PDP)
2. PAP -> PDP Response returns list of Cohorts associated with specified PDP and their effective and expiration date/times
3. PDP -> PAP Request current policy list for specified Cohort
4. PAP -> PDP response – returns list of policy ids for specified Cohort, optionally a size estimate may be returned for each policy
PDP determines which Cohorts it wishes to obtain. For each Cohort it determines which policies it does not already have. It then requests the missing policies and constructs a local copy of the Cohort. It may make use of the size information to construct the queries.
5. PDP -> PAP Policy request – list of Policy Ids of policies to be returned
6. PAP -> PDP Policy response – Returns Policies and Policy Sets.
PAP is allowed to send subset of Policies requested. If a requested policy does not exist, an error must be returned identify the Policy in question. In this case, the PDP should go back to sending a request for the policy list for that Cohort.
PDP continues sending policy requests until all needed policies have been received. Then the effective date/time should be checked. If it is missing or in the past, the update should be done immediately. Otherwise the update should be delayed until the effective date/time is reached.
In either case, when the update is performed, the PDP stops evaluation, atomically adds new policies and deletes obsolete ones, then resumes policy evaluation.
Status: OPEN
CHAMPION: Hal
66. Missing attributes may be underspecified
I did a somewhat detailed analysis of "Example two" in the core spec from the point of view of understanding how fine grained authorization (fga) (applying resource attrs to az decision) was implemented and came across a number of items that I think need to be addressed especially in potential interoperability situations. I will put all in one issue initially, we can decide if it needs to be broken out later.
1. line 1090-91 describing ResourceContent. In both the core spec and the sample messages, the ResourceContent contains the following:
<md:record xmlns:md="urn:med:example:schemas:record"
- xsi:schemaLocation="urn:med:example:schemas:record
<md:patient>
<md:patientDoB>1992-03-21</md:patientDoB> <md:patient-number>555555</md:patient-number>
</md:patient>
</md:record>
</ResourceContent> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="xs:string">
- //med.example.com/records/bart-simpson.xml#
xmlns(md=http:www.med.example.com/schemas/record.xsd) xpointer(/md:record/md:patient/md:patientDoB)
- //med.example.com/records/bart-simpson.xml#
</Attribute>
While I recognize that the example itself is not intended to be perfect, it provides a convenient context for raising the following questions/issues, especially wrt fga.
- If this is a first request from a PEP, why is the PEP supplying patient-number on line 1056? This looks like a required attr to evaluate Rule 1 (line 1141), if the requestor is the patient, but this example the requestor is the physician.
- The physician-id is supplied in the request (line 1044), but the only rule it appears in is rule 3 (line 1522). This rule only allows "write" access (line 1507), so I expect this request would probably fail as it is currently set up. i.e. we would need to add a "read" action to rule 3 or add a physician-id test to rule 1.
Rule 1 requires a Subject attribute patient-number (line 1134) to match the patient-number in the requested resource record (line 1141). Presumably a <MissingAttributeDetail> could be returned, somehow identifying these 2 attributes to the PEP.
Rule 2 requires a patientDoB resource attr (line 1297), a parent-guardian-id subject attr (line 1363), and a parentGuardianId resource attr (line 1371). Similarly a <MissingAttributeDetail> could be returned requesting these.
- Assuming this to be the case, one question I have is how does the
<MissingAttributesDetail> tell the PEP whether the attributes that are missing should be resubmitted as part of the Subject or as part of the Resource? This info is provided in the Request from the xml structure, however, the <MissingAttributeDetail> does not have equivalent structure to make such distinctions.
The above is intended just to give an example of questions that occur for this particular example, but it is my opinion that it is symptomatic of a general problem of how PEPs are supposed to know how to construct the proper RequestContext necessary, in general, for complex scenarios that require substantive fga attrs.
In these more complex fga scenarios it is likely that <MissingAttributeDetail> will be typically needed to collect all the required attributes. Therefore, I believe some more robust mechanisms, possibly using MissingAttributeDetail as a good starting point will be needed to adequately define operation in this area.
In this context as well, it is likely that xpaths are probably not the way to go since they are only applicable to certain types of resources (xml-based) and those resource structures are likely to change in time, and these changes should not percolate into the enterprise Policy arena. Therefore, mechanisms such as vocabularies should be recommended usage here with the PEP being responsible for mapping the vocabulary item to the particular resource physical access path such as the xpath.
Status: OPEN
CHAMPION: Rich
75. Defining an interface for closely coupled PEP/PDP
Status: OPEN
At the TC meeting on 11th Sept 2008 it was decided that this issue is best addressed by a separate profile, and that this issue is not on the critical path to 3.0.
CHAMPIONS: Rich and Prateek
82. PRIVACY: error in FunctionId
The name of the function referred in the condition of the matching purpose rule is wrong. Instead of being "urn:oasis:names:tc:xacml:2.0:function:regexp-string-match" it's "urn:oasis:names:tc:xacml:2.0:function:string-regexp-match".
Reported on xacml-comment by Alejandro Cartas
WD 3 of privacy 3.0 contains a fix for this. No errata for 2.0 exists yet.
Status: OPEN
Champion: ?