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] SAML 2.0 Profile of XACML 2.0, Version 2, WD 2, 26 June2006

Hi Anne,

I have two comments on the revised draft:

1. Line# 763-767, Section 4.4 Element <xacml-samlp:XACMLPolicyQuery

I think we should keep the xacml:Target element in the 
xacml-samlp:XAMLPOlicyQuery element as an optional element. It will help 
a distributed PDP to get necessary target specific policies (i.e. subset 
of policies) from a centralized PAP. As you have said in the 
specification, it might be difficult to determine target specific 
policies for particular scenario. However, we should keep the 
specification broad and not disallow using this element, when it may 
efficient to use this element.

2. Line# 772-774, Section 4.4 Element <xacml-samlp:XACMLPolicyQuery

It is mentioned in the specification that, "If the 
<xacml-samlp:XACMLPolicyQuery> contains no element instances, then the 
PAP SHOULD return all policies that are authorized and appropriate for 
use  by the requester."

I am thinking a scenario where this kind of query may return a large 
number of policies. For example, a PDP wants to get all applicable 
policies form a centralized PAP. It might take considerable amount of 
time to get those policies. If there is a network outage or any other 
dependent service goes down, while policy retrieval is in progress then, 
PDP has to start downloading policies from the beginning.

My suggestion is to include xacml:PolicySetIdReference and 
xacml:PolicyIdReference elements in the 
xacml-saml:XACMLPolicyStatementType element. If the number of requested 
polices are large enough (determined by PAP) then it might decide to 
send xacml:PolicySetIdReference/xacml:PolicyIdReference instead of 
actual xacml:Policy/xacml:PolicySet. Then, PDP can make additional 
requests to get them using specific 
xacml:PolicySetIdReference/xacml:PolicyIdReference elements.


Kamalendu Biswas
Oracle Fusion Middleware


Anne Anderson wrote:
> I have submitted Working Draft 2 of the revised SAML 2.0 Profile to 
> the document repository at 
> http://www.oasis-open.org/committees/download.php/18921/xacml-2.0-profile-saml2.0-v2-wd-2.zip 
> It is also linked off the TC Home Page under "Work in Progess".
> I. Description of changes from Working Draft 1:
> - In response to comments from SAML and XML experts, this draft does 
> not define new XACML elements for Statements, Assertions, Responses, 
> or Advice.  Instead, it describes in detail and with examples exactly 
> how to include instances of the new XACML extension types - 
> XACMLAuthzDecisionStatementType and XACMLPolicyStatementType - in 
> standard SAML elements.
> - In response to comments from XACML TC members, the name of the 
> profile has been changed from "SAML 2.0 Profile of XACML 2.1" to "SAML 
> 2.0 Profile of XACML 2.0, Version 2".  TC members objected to "2.1" 
> since this is still a profile of XACML 2.0.  File and schema names 
> have been changed accordingly.
> - In response to comments from users of the previous profile, this 
> draft describes use of the standard SAML "ID" XML attribute in the new 
> XACMLAuthzDecisionQuery and XACMLPolicyQuery elements, and the 
> standard SAML "InResponseTo" XML attribute in the standard SAML 
> Response element as a way of correlating responses with requests.
> II. Description of changes from "SAML 2.0 Profile of XACML 2.0" OASIS 
> Standard carried over from Working Draft 1 and Errata:
> - In XACMLAuthzDecisionStatementType, change "ReturnResponse" to 
> "ReturnContext" in the description
> - In the description of Authorization Decisions, change "in the 
> Response to an <XACMLAuthzDecisionStatement>" to "in the Response to 
> an <XACMLAuthzQuery>".
> - Allow an XACMLAuthzDecisionQuery to include an XACML Policy or 
> PolicySet for use in evaluating that query only.
> In both schemas:
> - Change targetNamespace value from 
> "urn:oasis:xacml:2.0:saml:assertion[protocol]:schema:os" to 
> "urn:oasis:names:tc:xacml:2.0:profile:saml2.0:v2:schema:assertion[protocol]" 
> [":v2:" added in WD 2]
> - Change xmlns:xs="http://www.23.org/2001/XMLSchema"; to 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> - Remove "xs:" qualifier before names defined in XML Schema.  For 
> example "<xs:complexType>" becomes just "<complexType>"
> In Assertion schema:
> - Omit xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" and 
> corresponding import namespace, since SAML protocol schema is not 
> referenced
> - Define 
> xmlns:xacml-saml="urn:oasis:names:tc:xacml:2.0:profile:saml2.0:v2:schema:assertion" 
> [":v2:" added in WD 2]
> - Change schemaLocation for imported SAML namespace from 
> "http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security"; 
> to 
> "http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd"; 
> - In definition of XACMLPolicyStatementType, change 
> base="samlp:StatementAbstractType" to base="saml:StatementAbstractType"
> In Protocol schema:
> - Define 
> xmlns:xacml-saml="urn:oasis:names:tc:xacml:2.0:profile:saml2.0:v2:schema:assertion" 
> and 
> xmlns:xacml-samlp="urn:oasis:names:tc:xacml:2.0:profile:saml2.0:v2:schema:protocol" 
> - Add <import 
> namespace="urn:oasis:names:tc:xacml:2.0:profile:saml2.0:v2:schema:assertion" 
> schemaLocation="http://docs.oasis-open.org/xacml/2.0/xacml-2.0-profile-saml2.0-v2-schema-assertion-wd-2.xsd"; 
> />

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