[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Resource sets and resource string semantics
I think it would be useful to allow Attribute Authorities to issue assertions containing strings of the form http://www.hp.com/* This being the case I believe we need to agree on the semantics of such assertions (to be consumed by PDPs). I would like to separate this from discussion of PDP/PEP interaction, although I agree it is important that is fixed too. I would like to see more powerful ways of expressing sets of resources than the simple example above. However, I note that some feel that regular expressions and the like are too onerous for SAML at this time. Perhaps this can be picked up in SAMLv2. Nigel. > -----Original Message----- > From: Platt, Darren [mailto:dplatt@securant.com] > Sent: 15 May 2001 02:20 > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC