[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Preliminary review of WS-XACML
Hi Prateek, Briefly for the moment, but more later: Use case: Administrator designs policy to protect resource that requires attributes: x,y,z x,y are available internally or from user authentication context/ldap etc, however, attr z must be obtained by user and accompanied by request. Therefore, admin wants to advertise "z" and include it somehow in ws-policy so user client can work w user to obtain z before submitting request. That's all I can say in this short time. Thanks, Rich Prateek Mishra wrote: > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]