OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]