[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Preliminary review of WS-XACML
Prateek, All, Wasn't this issue opened up precisely because users had asked Hal that it should be brought up to a higher level towards a standard because they were using it? Correct me if I am wrong. I cannot vouch for how many would want to use it since I am no expert on WS-Policy, but if users are asking for it, I am in favour of making it more than just a working draft. There is one technical issue which needs to resolved: the recent changes to xpaths in 3.0 means that it needs to be updated. And, I don't understand one issue: when a service posts a privacy requirement, how does the client become bound to the requirement? I sent an email to Anne asking for clarification. It might be just that I have misunderstood the proposal, or there is a mode of policy exchange which I am not aware of. Regards, Erik Prateek Mishra wrote: > 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 >> > > --------------------------------------------------------------------- > 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]