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