[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Preliminary review of WS-XACML
This seems an incredible amount of effort to reach some very modest goals... As Ramana points out, there are existing SecurityPolicy extensions and extension points that could support the required functionality I dont see the use-case where fine-grained Az needs to be advertised across enterprise or other boundaries; again, this seems an interesting project but I dont see a lot of folks asking for this... - prateek > 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 >> >> > > > --------------------------------------------------------------------- > 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]