RE: Resource sets and resource string semantics

[Hal Lockhart <hal.lockhart@entegrity.com>]

This raises a number of issues.

1. On the understanding that in SAML returning a wild carded decision
assertion is purely an optimization that must be explicitly asked for by the
requestor, I withdraw my objections. I still think this optimization is
unlikely to be useful in practice, but if others disagree, I am willing to
go along with it. Is the wildcard constrained to encompass the resource in
the orginal request?

2. In a modern web environment, the existence of 

http://www.mumble.com/x/y/z/a
and
http://www.mumble.com/x/y/z/b

by no means implies that 

http://www.mumble.com/x/y/z

is a directory. This may have been true in the mid 90's, but it is not true
today. More likely all three resolve to distinct, dynamic pages. SAML
functionality based on the premise that the path syntax represents a
directory heirarchy, rather that merely an heirachical namespace would be an
unreasonable constraint on local implementation. I am not saying the current
proposal does this, I am just warning about going in that direction.

3. Its important to keep XACML separate. Since XACML is for policy exchange,
it will need the richest possible language to express policy assertions. As
I understand the current charter, it must be able to represent any possible
resource name that can be expressed in XML (I don't think that excludes
anything) and is not limited to XML documents.

4. According to RFC 2396, http:\\...\document.html\Body\H1 is not a legal
URI. I am aware that Microsoft is under the opposite impression, but I
thought this was a open standards activity. At the least, if we are going to
use "URI" we should identify the document defining it, if it is not RFC
2396.

Hal


> -----Original Message-----
> From: Phillip Hallam-Baker [mailto:pbaker@verisign.com]
> Sent: Friday, May 11, 2001 4:06 PM
> To: 'Simon Y. Blackwell'; Phillip Hallam-Baker;
> 'xacml@lists.oasis-open.org'; 'security-services@lists.oasis-open.org'
> Subject: RE: Resource sets and resource string semantics 
> 
> 
> Simon, 
> 
> 	I think we are on the same wavelength (I used the term 
> HP since Joe
> and Nigel had advanced similar arguments).
> 
> 	In the case that the authorization needs to go down to 
> the element
> level etc., I would see that as a matter for XPATH and 
> XPOINTER (whatever).
> 
> 	In fact looking at some of the dot.net stuff the 
> boundary between
> the document and contents can become blurred. One could specify an
> individual element within the document:
> 
> http:\\...\document.html\Body\H1 (or some such)
> 
> 	Provided the issuer and relying party both agree on what the
> interpretation of the URI should be we get interoperability.
> 
> 	Equally if someone wanted to implement the RE based matching I
> described earlier there would be nothing to stop them, 
> however I don't think
> we want to insist that every SAML application implement full 
> RE matching.
> 
> One way to support this is through the respond element:
> 
> <Respond>Wildcard</Respond>
> 
> <Respond>urn:47598q75987:Regular-Expressions</Respond>
> 
> And so on...
> 
> 		Phill
> 
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
> 
> 
> > -----Original Message-----
> > From: Simon Y. Blackwell [mailto:sblackwell@psoom.com]
> > Sent: Friday, May 11, 2001 1:45 PM
> > To: 'Phillip Hallam-Baker'; 'xacml@lists.oasis-open.org';
> > 'security-services@lists.oasis-open.org'
> > Subject: RE: Resource sets and resource string semantics
> > 
> > 
> > Re HP ... Aha!
> > 
> > Re: "I think it is entirely appropriate to support authorization
> > assertions that refer to all the files in a directory 
> > sub-tree." ABSOLUTELY
> > 
> > Re: "I think it would be onerous to support arbitrary regular 
> > expression based wildcards however." ONEROUSE YES ... but 
> > does this mean
> > that regular expression based wild cards should not be 
> > suported in general.
> > Consider the case of an XML document in which we wish to 
> apply access
> > controls to subcomponents of the document and the auth 
> > decision needs to be
> > made based on the contents of the subcomponents themselves 
> > when compared to
> > some attribute of the requestor. Since it would be even more 
> > onerous, and
> > perhaps impossible, to determine, define, and dictate beforehand the
> > structure of the XML files whose content is being 
> controlled prior to
> > defining a policy language that can be mapped to the files, 
> > then it would
> > seem must support arbitrary regular expressions, at least for 
> > intrafile
> > access. Onces one supports it for intrafile access, I can't 
> > see a reasonable
> > reason not to support it for extrafile access. Granted, this 
> > could result in
> > very hairy and conflicting policy statements on the part of 
> > policy managers;
> > however, this is a user problem. It seems to regress into the 
> > old argument
> > that the tool (in this case SAML and XACML) is by its 
> nature neutral;
> > however, if you want to kill yourslef with it you can.
> > 
> > I would like to keep things simple; however, if we do so at 
> > the cost of
> > people subsequently writing hacks to support more power and 
> > they put those
> > hacks into applications, then we have even more difficult 
> > security problems
> > to address.
> > 
> > -----Original Message-----
> > From: Phillip Hallam-Baker [mailto:pbaker@verisign.com]
> > Sent: Friday, May 11, 2001 8:40 AM
> > To: 'Simon Y. Blackwell'; 'security-services@lists.oasis-open.org'
> > Subject: RE: Resource sets and resource string semantics
> > 
> > 
> > 
> > 
> > > Not to be blatantly diagreeable, but every web server I have ever
> > > administered grouped files by function. It happened that 
> > > function generally
> > > coincided with security settings, but not always.
> > 
> > And what HP were asking for was the ability to support the
> > equivalent of directory level controls in the case that they
> > were appropriate.
> > 
> > I think it is entirely appropriate to support authorization
> > assertions that refer to all the files in a directory sub-tree.
> > 
> > I think it would be onerous to support arbitrary regular 
> > expression based wildcards however.
> > 
> > http://www.hp.com/secret/*		YES
> > http://www.hp.com/secret/xyz*.htm	NO!
> > 
> > 
> > 	Phill
> > 
> > > The issue 
> > > being, which is
> > > easier to do manage security differences in a group of files 
> > > or manage and
> > > develop code that references file locations which don't 
> > correspond to
> > > application function. Although it brings up some other 
> > issues, the old
> > > Apollo OS handled this pretty well with symbolic links and 
> > > access control on
> > > the links.
> > > 
> > > -----Original Message-----
> > > From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> > > Sent: Monday, May 07, 2001 1:59 PM
> > > To: 'Hal Lockhart'; Philip Hallam-Baker; 'Edwards, Nigel';
> > > security-services@lists.oasis-open.org
> > > Subject: RE: Resource sets and resource string semantics
> > > 
> > > 
> > > I entirely disagree with the statements made by Hal. 
> > > 
> > > First every Web server I have ever administered has grouped 
> > documents
> > > together on the basis of access rights. I don't think it is 
> > > unusual for this
> > > to take place. I think it is the overwhelming norm.
> > > 
> > > The same was true when I built database systems and ran large 
> > > VMS systems, I
> > > would group files into directories by function and by access 
> > > permissions. In
> > > most cases the two went together.
> > > 
> > > Second who said anything about the PDP volunteering information? 
> > > 
> > > PEP: Can Alice access http://www.hp.com/finance/fred.xls 
> > > 	[And what neighboring files can Alice access]
> > > PDP: Yes, and Alice can access http://www.hp.com/*
> > > 
> > > To get a wildcard response the client should affirmatively 
> > request it:
> > > 
> > > <Respond>
> > >     <string>Decision 
> > >     <string>Assertion
> > >     <string>ResourceWildcard
> > > 
> > > I don't think that the use case raised by HP was rare or 
> > > unusual in the
> > > slightest. It is the most commonplace type of operational 
> > > optimization an
> > > O/S level PEP is likely to perform.
> > > 
> > > The counter-example is VMS where the lack of a means of 
> > > saying 'everything
> > > in this directory and descendents  has these permissions' led 
> > > to some pretty
> > > wierd ACL propagation rules which were a nightmare.
> > > 
> > > In fact since many Web protocols specify a default resource, 
> > > having a means
> > > of distinguishing the directory permissions from permissions 
> > > on the default
> > > resource is likely to be essential.
> > > 
> > > 
> > > I think it is much better that the standard propose a means 
> > > of optimizing
> > > the PEP-PDP conversation rather than have multiple ad-hoc 
> > optimization
> > > schemes develop.
> > > 
> > > I do not see an interoperability problem here:
> > > 
> > > 	1) A Client that does not support Resource Wildcard 
> > > never specifies
> > > it in a request
> > > 	2) A server that does not support Resource wildcard on 
> > > part or all
> > > of the database simply ignores the Respond keyword and does 
> > > not generate a
> > > wildcard resource in the response.
> > > 
> > > 
> > > 		Phill
> > > 
> > > Phillip Hallam-Baker FBCS C.Eng.
> > > Principal Scientist
> > > VeriSign Inc.
> > > pbaker@verisign.com
> > > 781 245 6996 x227
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> > > > Sent: Monday, May 07, 2001 4:47 PM
> > > > To: 'Philip Hallam-Baker'; 'Edwards, Nigel'; Hal Lockhart;
> > > > security-services@lists.oasis-open.org
> > > > Subject: RE: Resource sets and resource string semantics
> > > > 
> > > > 
> > > > I think before we discuss HOW to do this sort of thing we 
> > > > should discuss
> > > > whether it desirable.
> > > > 
> > > > > The way I would see the conversation going is:
> > > > > 
> > > > > PEP: Can Alice access http://www.hp.com/finance/fred.xls 
> > > > > PDP: Yes, and Alice can access http://www.hp.com/*
> > > > > 
> > > > > PEP: Can Alice access http://www.hp.com/finance/mary.xls
> > > > > PEP-Cache: Yes
> > > > 
> > > > I feel very uncomfortable about the PDP volunteering 
> > > > information it has not
> > > > been asked for. It seems to add various kinds of risks 
> > without clear
> > > > benefit.
> > > > 
> > > > > I don't like the idea of unconstrained wildcard matching etc. 
> > > > > However simple
> > > > > hierarchical partitioning is probably enough for what we 
> > > > > need. After all the
> > > > > admin will probably organize directories so that the 
> > > wildcards match
> > > > > cleanly.
> > > > 
> > > > Our experience has been that this is not the case. Names are 
> > > > chosen for
> > > > reasons other that access patterns. A naming scheme which 
> > > > works for one
> > > > category of user does not fit another. 
> > > > 
> > > > This would seem to me to optimize a rather rare situation, 
> > > > while adding
> > > > various risks.
> > > > 
> > > > Hal
> > > > 
> > > 
> > > 
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: 
> > > security-services-request@lists.oasis-open.org
> > > 
> > 
> 
> 
>