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] FYI: WS-Federation charter includes section on authorizationservices


So I guess we disagree, as we are very familiar with XACML and we believe that the item I listed are not covered in any version of XACML, web services security cover other mechanisms than SAML. So I suggest that you join the WSFED TC and make your points

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for Prateek Mishra <prateek.mishra@oracle.com>Prateek Mishra <prateek.mishra@oracle.com>


          Prateek Mishra <prateek.mishra@oracle.com>

          04/09/2007 10:20 AM


To

XACML TC <xacml@lists.oasis-open.org>

cc

Anthony Nadalin/Austin/IBM@IBMUS

Subject

Re: [xacml] FYI: WS-Federation charter includes section on authorization services

Hi Tony,

I disagree with your statement that WS-Fed charter includes materials
that "do not appear to be addressed by XACML".

Let me put it differently - it would be very surprising that XACML,
which has gone thru a systematic development process over five years
by key players of the access control community and has evolved thru
three versions,
wouldn't have addressed many of the issues hinted in the WS-Fed charter.

I recommend you take the time to review the XACML 2.0 specification. It
is available from:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#XACML20

I have added specific responses to your statements below:

[AN]
>
> So I'm not sure what you are trying to point out here but these are
> the concepts anticipated in the WS-Fed charter which do not appear to
> be addressed by XACML:
>
> 1) We want to enable the addition of an authorization context to
> WS-Trust RSTs to provide additional information for the STS to base
> its response upon.
>
[\AN]

Sure, that is a reasonable requirement and the main insight required is
that XACML can be layered on top of many existing protocols.

For example, Section 3.0 the SAML profile of XACML, explains how
<xacml:request> and <xacml:response> elements can be layered on top of
<saml:AuthZDecisionQuery> and <saml:AuthZDecisionStatement>.

[AN]
>
> 2) We want to enable the implementation of an Authorization service
> using the existing WS-Trust RST/RSTR protocol + the existing security
> token data structure to return authorization information. The goal is
> to allow either a client push, or back-end server-server communication
> path via existing wire protocols to for transmitting authorization data.
>
[\AN]

See my comment above. Any reasonably structured standard (e.g., SAML,
XACML) can be layered appropriately over other protocols. I would
recommend an appropriate profile of <xacml:request> and <xacml:response>
layered over WS-Trust RST/RSTR.

[AN]
>
>
> 3) We want to allow the possibility of expressing authorization
> decisions as a claims transformation process. This is not focused on
> the transmission of authorization policy, which seems to be the major
> focus of XACML.
>
[\AN]

XACML has been used in many different contexts, including transmission
of authorization policy and processing of authorization decisions. This
information
available from a review of the specifications and other materials.

I dont see any issue in modeling the so-called "claims transformation"
in XACML. As I see it, this is actually a subset of the overall XACML
authorization model
and could easily be described as such. XACML <response> also includes
some additional structure - classifying claims/attributes into three
groups - subject, resource and environment and provides valuable
infra-structure to add new claims/attributes.


GIF image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]