[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] Resource text
Phill, The proposed text is fine for me with just one addition and a nit (embedded below). I hope the addition is just a clarification and not going to stir up another hornet's nest:-). The clarification needed is to say what's meant by "canonical form". Now, unfortunately rfc2396 doesn't define this explicitly and I don't know of an explicit definition (not even in the canonical XML rec [1]!). Would the following do for now? I'm quite happy that we tweak/tighten the definition now or later. By the "canonical form" of a URI we mean an absolute URI (i.e. no relative URIs) which is the shortest of all the equivalent URI strings, where URI equivalence is defined according to [RFC2396]. For example, the URI "http://foo.com:80/go/../go/to/" is not in canonical form, but "http://foo.com/go/to" is in canonical form. Note that if a URI is partly or entirely case-insensitive, then there will be more than one "canonical form" for that URI such that a case sensitive matching rule would consider that the strings differ (e.g. "HTTP://Foo.cOm/go/to" is "another" canonical form of the URL above). Btw: nice one - getting around the coformance muddle by imposing security conditions - I like that! Stephen. [1] http://www.w3.org/TR/xml-c14n [RFC2396] ftp://ftp.isi.edu/in-notes/rfc2396.txt "Hallam-Baker, Phillip" wrote: > [...] > 2.4.4. Element <AuthorizationDecisionStatement> > > The <AuthorizationDecisionStatement> element supplies a statement by the > issuer that the request for access by the specified subject to the specified > resource has resulted in the specified decision on the basis of some > optionally specified evidence. > > The resource is identified by means of a URI. In order for the assertion to > be interpreted correctly and securely the issuer and relying party MUST > interpret each URI in a consistent manner. Failure to achieve a consistent > URI interpretation can result in different authorization decisions depending > on the encoding of the resource URI. To avoid ambiguity resulting from > variations in URI encoding SAML applications SHOULD employ the URI > cannonical form wherever possible as follows: > > * The assertion issuer SHOULD encode all resource URIs in canonical > form. > * Relying parties SHOULD convert resource URIs to cannonical form prior > to processing. > > Inconsistent URI interpretation can also result from differences between the > URI syntax and the semantics of an underlying file system. Particular care > is required if URIs are employed to specify an access control policy > language. The following security conditions should be satisfied by the > system which employs SAML assertions: > > * The URI syntax is case sensitive. If the underlying file system is s/The URI syntax is/Parts (see [RFC2396]) of the URI syntax are/ > case insenstive a requestor SHOULD NOT be able to gain access to a denied > resource by changing the case of a part of the resource URI. > > * Many file systems support mechanisms such as logical paths and > symbolic links which allow users to establish logical equivalences between > file system entries. A requestor SHOULD NOT be able to gain access to a > denied resource by creating such an equivalence. > > The <AuthorizationDecisionStatement> element is of type > AuthorizationDecisionStatementType, which extends > SubjectStatementAbstractType with the addition of the following elements (in > order) and attributes: > > Resource [Optional] > A URI identifying the resource to which access authorization is sought. > > [Also fix section 3.3.5 to reference] > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC