[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: xacml 2.0 wish list
Please find attached a summary of our requirements in the same format as Anne used for her 2.0 work item list. -Frank. ------------------------------- 1. Policy Authority Delegation The ability to associate an authorization authority with a particular target domain. A policy decision has to be evaluated whether a certain subject is authorized by the PEP's higher level policy to provide authorization decisions for a target domain. Arguably, the current XACML spec has the implicit assumption that whoever we send the authorization decision request to, is authorized to provide that decision. By making this explicit, the boottrapping of what authorities to trust is enabled through configuration, and it allows for the dynamic delgation of rights in the form of true xacml policy. This implies that there would be always (at least) two authorization decisions: is the authority allowed to provide a decision for that target AND is the requester allowed to invoke the operation. There could be multiple of these authorization decisions for more complex delegation scenarios. Status: ??? 2. Passing of explicit policy-set/policy/rule to the Authorization Decision Query (Anne's item# 17 ?) If a third party is empowered to decide on the authorization policy for a target domain, it would allow for a push-mode of operation, where the requester would present the PEP with an authorization assertion that would consist of xacml policy statements. The associated model is identical to the "Policy Authority Delegation", except that the policy statements are presented in the authorization decision request. This is probably the same as Anne's item# 17, but I was missing the reference to policy delegation. Status: ??? 3. Attribute Issuer as Subject The current attribute issuer type is a string. This restriction doesn't allow one to easily point at an issuer as Subject, and it doesn't allow for any path validation that goes more than one level deep. By allowing an attribute issuer of type subject, one could cater for more complex use-cases that involve policy delegation. Status: ??? 4. Standardize naming to specify policy rules for the requestor's authorization policy The current 1.0 spec seems to be somewhat silent on the requestor's side authorization decision to see whether the requestor's policy allows the service provider to service the request. There are subject categories defined for access-subject, recipient-subject, and intermediary-subject. I guess we could use the recipient-subject for the service provider's subject, although I have the feeling that that was not its intension. Maybe we should define/standardize a "provider-subject" to more clearly distinguish the context where the access control decision is made. Status: ??? 5) XACML wsdl/porttype definition for <Request>/<Response> exchange If we would use a centralized "authorization" service, it seems most natural to abstract the decision request and response messages between the context handler and the PDP into a wsdl/porttype definition. Status:??? 6) porttype/operations to ask for required attributes This allows a requester to query the resource's authorization policy for the required attributes for a Target such that it "knows" which one are missing and would have to be retrieved and presented with any request. If I'm not mistaken, Rebekah (@nasa) has implemented something like this in her prototype. Status: ??? 7) Standardize primitives to express policy to reveal missing attributes Quoting from the spec: <quote> "urn:oasis:names:tc:xacml:1.0:status:missing-attribute 2805 A PDP MAY choose not to return any <StatusDetail> information or MAY choose to return a 2806 <StatusDetail> element containing one or more xacml-context:Attribute> elements. If 2807 the PDP includes <AttributeValue> elements in the <Attribute> element, then this indicates 2808 the acceptable values for that attribute. If no <AttributeValue> elements are included, then 2809 this indicates the names of attributes that the PDP failed to resolve during its evaluation. The list 2810 of attributes may be partial or complete. There is no guarantee by the PDP that supplying the 2811 missing values or attributes will be sufficient to satisfy the policy. </quote> As mentioned, the returning of the missing attribute info is sensitive information and should itself be subject to policy. Status: Anne gave a possible solution of how to express this, but it would require the standardization of names/operations for interoperability. -- Frank Siebenlist franks@mcs.anl.gov The Globus Project - Argonne National Laboratory
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]