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


I don't think a PEP can make any assumptions about what kind of queries a
PDP can answer without querying the PDP, i.e. there are no stupid questions.
There is also nothing to say that the stuff in http://www.hp.com/* is
actually a list of files. http://www.hp.com/* might simply be a virtual
pointer to any resource accessed via http://www.hp.com/. 

You are correct in the clearer reformulation of my question, thanks! However
the core questions still remain, should the PDP be able to enumerate the
resources available to a requestor or role given an expression to match
against resource policy constraints in the PDP. The pattern might be an
XPath or even a regular expression. The PDP would seem to have several
options based on its configuration, e.g. reject non-explict patterns,
enumerate for non-explicit patterns, reply yes to non-explicit patterns if
the result set is not empty (but don't enumerate) or reply no for the
converse.

Once again, the enumerating may open other security holes. Should the
protocol be designed in such a way as to preclude it? It seems to me this
will be a crucial point of intersection between SAML and XACML.

-----Original Message-----
From: Platt, Darren [mailto:dplatt@securant.com]
Sent: Tuesday, May 15, 2001 12:43 PM
To: 'Simon Y. Blackwell'; security-services@lists.oasis-open.org
Subject: RE: Resource sets and resource string semantics


I don't think a PDP would necessarily know how to answer that question:  

> PEP: Can Alice access http://www.hp.com/* 

If the PDP is configured with a policy that says Alice is or isn't allowed
access to the http://www.hp.com/* directory, then it is easy to answer that
question as a yes or no.  I believe that is a reasonable question to ask and
answer.  But I think (based on your example) what you are really asking is
...

> PEP: Which resources can Alice access in http://www.hp.com/* 

... and I think that is too complex a question for SAML.  We can't assume
that the PDP knows about all of the files are in the http://www.hp.com
directory in order to give the answer. 

Regards,

Darren



> -----Original Message-----
> From: Simon Y. Blackwell [mailto:sblackwell@psoom.com]
> Sent: Tuesday, May 15, 2001 4:54 AM
> To: security-services@lists.oasis-open.org
> Subject: RE: Resource sets and resource string semantics
> 
> 
> > PEP: Can Alice access http://www.hp.com/finance/fred.xls 
> > PDP: Yes, and Alice can access http://www.hp.com/*
> 
> If the above is not acceptable, then is the below:
> 
> PEP: Can Alice access http://www.hp.com/* 
> PDP: Yes, Alice can access http://www.hp.com/foo.txt,
> http://www.hp.com/bar.txt, http://www.hp.com/cdr.txt, 
> http://www.hp.com/car.txt, http://www.hp.com/finance/fred.xls
> 
> In short are exploratory queries allowed? Note, this does 
> give the PEP the
> info it wanted, i.e. is access to Fred.xls allowed. 
> 
> This second approach seems to bring up issues in that the 
> more one knows
> about access priveleges the better chance one has of 
> circumventing them. On
> the other hand, I can imagine a situtation in which certain 
> roles should be
> given the ability to make queries of the above type, perhaps for
> administrative purposes. Granted, this type of access would 
> seem to be out
> of scope for SAML, although for a closed system it would have to be
> expressible in SAML.
> 
> -----Original Message-----
> From: Platt, Darren [mailto:dplatt@securant.com]
> Sent: Monday, May 14, 2001 6:20 PM
> To: 'Philip Hallam-Baker'; 'Edwards, Nigel'; 'Hal Lockhart';
> security-services@lists.oasis-open.org
> Subject: RE: Resource sets and resource string semantics
> 
> 
> > PEP: Can Alice access http://www.hp.com/finance/fred.xls 
> > PDP: Yes, and Alice can access http://www.hp.com/*
> 
> I don't think we should be passing policy back with the authorization
> decision. 
> 
> 
> > Note that another possibility is that the PEP is not a file 
> > system. If the
> > access control policy or permissions/whathaveyou are embedded in the
> > resource the PEP may be asking a question of the form 'Does 
> > Alice have the
> > Role X' or 'Does Alice have any resources in the set ..../*'
> 
> It is my understanding that the consensus of the TC was that 
> a PDP did not
> know how to make decisions, and would therefore not interact 
> in this way.
> This seems to be a PDP/PEP combination.
> 
> Regards,
> 
> Darren
> 
> 
> 
> 
> > -----Original Message-----
> > From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> > Sent: Friday, May 04, 2001 12:24 PM
> > To: 'Edwards, Nigel'; 'Hal Lockhart';
> > security-services@lists.oasis-open.org
> > Subject: RE: Resource sets and resource string semantics
> > 
> > 
> > 
> > All resources on the HP web site ???
> > 
> > How about http://www.hp.com/*
> > 
> > or if we want to avoid any possibility of collision (although * is a
> > reserved URI character):
> > 
> > http://www.hp.com/ *
> > 
> > Or we could use an XPATH statement - maybe Eve can fill us in???
> > 
> > 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 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.
> > 
> > 
> > Note that another possibility is that the PEP is not a file 
> > system. If the
> > access control policy or permissions/whathaveyou are embedded in the
> > resource the PEP may be asking a question of the form 'Does 
> > Alice have the
> > Role X' or 'Does Alice have any resources in the set ..../*'
> > 
> > 	Phill
> > 
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> > 
> > 
> > > -----Original Message-----
> > > From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com]
> > > Sent: Friday, May 04, 2001 2:29 PM
> > > To: 'Hal Lockhart'; Edwards, Nigel;
> > > security-services@lists.oasis-open.org
> > > Subject: RE: Resource sets and resource string semantics
> > > 
> > > 
> > > Hi Hal,
> > > I should have made it more clear that I am worring about the kind
> > > of interaction that make take place between an Attribute Authority
> > > and a PDP, rather than a PDP and a PEP.
> > > 
> > > Sorry about that,
> > > Nigel.
> > > 
> > > > -----Original Message-----
> > > > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> > > > Sent: 04 May 2001 16:56
> > > > To: 'Edwards, Nigel'; security-services@lists.oasis-open.org
> > > > Subject: RE: Resource sets and resource string semantics
> > > > 
> > > > 
> > > > Nigel,
> > > >  
> > > > > The intent of this assertion is to specify authorizations 
> > > associated
> > > > > with Alice's account.
> > > > > 
> > > > > Suppose I want to issue an assertion allowing Alice to 
> > access all
> > > > > resources on a large web site with a dynamic resource set,
> > > > > e.g. http://www.hp.com/ 
> > > > > 
> > > > > Clearly it is not possible to enumerate the entire 
> > > resource set. So
> > > > > how do we handle this case?
> > > > > 
> > > > > It occurs to me that some may feel that this sort of 
> > > > assertion should
> > > > > be considered by XACML, rather than SAML. I guess one possible
> > > > > resolution is to leave it to XACML.
> > > > 
> > > > I don't understand the use case you have in mind. SAML is 
> > > not a policy
> > > > provisioning protocol. What sort of request might Alice have 
> > > > made to suggest
> > > > to the PEP that she might want to access all of www.hp.com? 
> > > > In the normal
> > > > case, there will be thousands of pages she can access and 
> > > > thousands she
> > > > cannot. Even with a really general language to express 
> > > > resources, e.g. reg
> > > > exp, It's going to be a long list.
> > > > 
> > > > It sounds to me that what you really ought to do is operate a 
> > > > PDP, which
> > > > receives Attribute Assertions (and perhaps Authorization 
> > > > Assertions) and
> > > > makes a decision whether to allow access. A PEP is supposed 
> > > > to be quite
> > > > simple.
> > > > 
> > > > > A related issue is the semantics of resource strings. I 
> > believe we
> > > > > need to define what these are. Suppose one of the 
> > > > <Resource> elements
> > > > > contains the following: http://www.hp.com/ 
> > > > > 
> > > > > What are the semantics: the home page or everything under it? 
> > > > > In my opinion
> > > > > serious security issues will arise if the asserting party 
> > > > and relying
> > > > > party apply different semantics.
> > > > 
> > > > Certainly this is something that the specification should 
> > > > make unambigious.
> > > > 
> > > > 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
> > > > 
> > > 
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: 
> > > security-services-request@lists.oasis-open.org
> > > 
> > 
> > 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-services-request@lists.oasis-open.org
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-services-request@lists.oasis-open.org
> 


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


Powered by eList eXpress LLC