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 onauthorization services


The functionality described here is for an authorization service that 
responds with an authorization token, a type of "capability" in access 
control model terms, that can then be presented to prove permissions. 
XACML core does not define such a service, but the "SAML 2.0 Profile of 
XACML Version 2," WD 3, 6 March 2007 
(http://www.oasis-open.org/committees/download.php/22765/xacml-profile-saml2.0-v2-wd-2.zip) 
does.  See Section 6 "Using an XACML Authorization Decision as an 
Authorization Token".  This section was originally part of the draft 
"Web Services Profile of XACML (WS-XACML)", but was moved to the SAML 
profile because it makes use of SAML Assertions to provide the ability 
for a 3rd party to authenticate the token.

Regards,
Anne

Prateek Mishra wrote On 04/06/07 09:44,:
> http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/email/archives/200703/msg00002.html 
> 
> 
> As far as I can determine, XACML isn't referenced anyplace in the charter.
> 
> 
> [quote]
> Authorization
> 
> An authorization service is a special type of Security Token Service 
> which provides decision brokering services for participants in a 
> federation. While the internal processing of an authorization service is 
> implementation specific, interoperability requires development of a 
> common model for interacting with authorization services, and extensions 
> to RST/RSTR mechanisms, as defined in WS-Trust [4], for communicating 
> request and policy inputs and decision outputs.
> 
> This work will focus on:
> 
> 1. Describing how an authorization service may be implemented as a 
> Security Token Service placed between the requestor and the desired 
> target service and granting/denying the request by issuing/not issuing 
> security tokens required by the target service. This includes describing 
> an abstract mechanism for comparing the claims required by the target 
> service to the claims proven by the requestor to determine if the 
> requestor is authorized.
> 
> 2. Defining the required function of an authorization service to ensure 
> that the requestor has presented and proven the claims required to 
> access the target service.
> 
> 3. Defining the syntax for conveying the authorization context of an RST 
> or RSTR, as defined in WS-Trust - that is, providing additional 
> contextual data that may influence token requests but may not be 
> included in the contents of the issued token. This includes defining 
> syntax for the following properties: a. Conveying the context item as a 
> name/value pair. b. Specifying the type of the context item via a URI. 
> c. Specifying the scope (requestor, target, action) of the context item 
> via a URI. d. Specifying the value as a simple string or a custom 
> representation.
> 
> 4. Defining a dialect for expressing common claims in a format-neutral 
> way in a manner consistent with the expression of Claim Dialects, as 
> defined in WS-Trust [4]. This includes defining syntax for the following 
> properties of a claim: a. Specifying the type of the claim via a URI. b. 
> Indicating whether the claim is required or optional. c. Specifying the 
> value of the claim as a string.
> 
> 5. Defining a profile of WS-Trust [4] in the form of processing rules 
> for RST/RSTR messages that must be observed by Authorization services 
> and requestors. This includes a description of the required use and 
> treatment of: a. Addressing headers as defined in WS-Addressing [9]. b. 
> Additional authorization context described above. c. The common claim 
> dialect described above.
> 
> [\quote]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692


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