[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 June 2006
Hi Kamalendu, Kamalendu Biswas wrote On 06/28/06 13:39,: > 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. Sending a Request Context is a good way to get a subset of policies. For example, if you want all policies applicable to subject-id="cn=Anne Anderson, O=Sun Microsystems, C=US", then include an Attribute with that value in the Request Context. Typically, I would think that XACMLPolicyQuery would either be used to retrieve policies relevant to a specific access request or to retrieve all policies relevant to some key value for the policy index. In both cases, a Request Context would be the most effective way to specify which policies are needed. Sending a <Target> element would be more general, but also much harder to compute, and I worry that without an algorithm, this will actually not be useful. > > 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. I think this is a good suggestion, with a modification. I suggest that we define a "number of requested policies is too large" error, that would be accompanied by the maximum number of policies that can be requested in one query from this PAP. If original Query included a Request Context [or Target], the list of policy references applicable to that Request Context [or Target] would be returned as error detail. If policy references were sent in the Query, there would be no need for the same list of policy references to be returned. I want to avoid the situation where a list of references is returned, and the requester immediately turns around and sends the entire list of references in a new query. Or where the requester has sent a list of references, and gets a "number of requested policies is too large" error, but has no idea how many references it is acceptable to send in one Query. Regards, Anne > > Regards, > Kamalendu > > -- > 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"; >> /> >> > -- 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]