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


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

Phillip Hallam-Baker (E-mail).vcf



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


Powered by eList eXpress LLC