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


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.



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