[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Preliminary review of WS-XACML
Prateek, The use case is for advertising and matching more fine grained access control and privacy policy requirements than provided by WS-SecurityPolicy. For example, WS-SP can say "Use a SAML Assertion". With WS-XACML you can say "access subject must have a Group attribute with the value of Administrator". WS-XACML also provides a more fine grained matching mechanism which is still syntactic in nature and does not require understanding of the semantics of the individual elements of the policy. WS-XACML uses syntax from XACML as well as P3P to meet these requirements. The use of XACML is not a goal, simply an implementation choice. Hal > -----Original Message----- > From: Prateek Mishra [mailto:prateek.mishra@oracle.com] > Sent: Thursday, June 19, 2008 9:26 AM > To: Rich.Levinson > Cc: xacml > Subject: Re: [xacml] Preliminary review of WS-XACML > > Rich, > > I still dont understand why there is an interesting use-case for > combining WS-Policy and XACML. > > Why would an entity advertise its authorization policies using > WS-Policy? An example would probably help folks like me who have a > superficial > understanding of XACML. > > - prateek > > At the last XACML TC mtg, Jun 5, I agreed to raise my concerns > > about WS-XACML to the TC list about pushing XACML policy > > expressions to the periphery in the sense that they would appear > > within WS-Policy assertions. > > > > In the process, I have reviewed the spec again and have a number > > of detailed comments to make about it, but have not yet had the > > time to assemble everything together in a cohesive fashion, so in > > the interest of keeping things moving, I will provide a summary of > > my findings here. > > > > As a result of this recent review, I have revised my thinking > > considerably > > about this spec. In particular, I believe in my early reviews of the > > material > > I had underestimated the scope of what the spec is trying either > > explicitly > > or implicitly to accomplish. At one level, I can now see it as a serious > > attempt at a "grand unification theory" of XACML and WS-Policy. > > > > The first major factor that the spec addresses is an abstraction of > > WS-Policy, > > itself. In particular, by representing assertions as combinations of > > Requirements > > and Capabilities, the spec makes explicit the structure of WS-Policy > > which is > > somewhat lost in the extremely abbreviated assertion representations > > found > > in specs such as WS-SecurityPolicy. (Note: there are background refs, > > which > > include a representation of WS-SP using the same constructs used in > > WS-XACML, > > which I have not reviewed yet, but does promise to be interesting.) > > > > The 2nd major factor the spec addresses is the notion of vocabularies, > > where > > a vocabulary is associated with a policy domain, such as authorization, > > privacy, or system-specific policy domains. In each vocabulary is a > > mechanism > > for expressing constraints on the variables within the vocabulary. The > > constraints, > > themselves, are abstracted so that basically any policy domain can be > > mapped > > into a XACML policy domain, and theoretically the client and server can > > determine dynamically whether their respective Requirements and > > Capabilities > > are mutually acceptable. Generally, the client does the evaluation of > > its own > > assertions vs the assertions it obtains from the server's wsdl. > > > > A 3rd major factor that is only lightly touched on is the notion that > > the "advertised" > > or "published" policy (i.e. that which appears as assertions in > > WS-Policy) MUST > > be a subset of the "internal" or enterprise policy used by the policy > > publisher > > for policy evaluation. There is a brief section (10) that talks about > > "managing" > > policies and how segments of internal policy might be tagged for > > external publication. > > > > A 4th significant factor is the list of supported constraint functions > > in Appendix A. > > These are clearly a subset of the more general xacml function set. > > Some information > > needs to be elaborated as to where the lines are drawn between > > core-xacml and > > ws-xacml functions and any significance there is to that boundary. > > > > It becomes quickly apparent that when we model the whole situation we > > have > > possibly 4 or 5 familiar actors involved in the overall process: > > > > - the service, itself, with its advertised wsdl > > - the client, with its own internal capabilities represented as > > assertions > > - the PEP, that intercepts the client request and is responsible > > for constructing > > a XACML authorization request based on the request and other > > available > > context. > > - the PDP, that processes the authorization request against its set > > of policies. > > - an admin entity that specifies the policy that is used by the PDP > > and the > > advertised policy that is published by the service. > > > > This is a broader model than that which is envisioned in the original > > xacml core > > spec, particularly the domain of advertised policy which until now has > > been > > pretty much the exclusive domain of WS-Policy. > > > > My basic conclusion is that the spec appears to be quite sound in > > concept and > > detail. However, the breadth of its scope is such that a significant > > amount of > > additional analysis is needed to determine if the abstractions are > > optimal for the > > overall problem space being addressed or whether they carry the inherent > > complexity and capabilities of xacml out to a space where a less complex > > expression mechanism would be more appropriate. > > > > It seems appropriate to me that the TC might want to spend some cycles > > addressing the high level problem space that WS-XACML is addressing > > and determine if we think this spec is worth promoting for the broad > > purposes that it appears capable of addressing. > > > > Thanks, > > Rich > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all your TCs in > > OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]