RE: Resource sets and resource string semantics

["Platt, Darren" <dplatt@securant.com>]

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

I agree with you there - there are no stupid questions.  I guess my concern
is that we don't hardwire certain types of questions or optimizations at the
expense of others.  I think we should decide if we should do any
optimizations at all, and be prudent about which we do.  I consider defining
standard ways of using paths and wildcards to define groups of web resources
an optimization, as well as using regular expressions.  I consider breaking
resources in to target/action or resource/action couplets as an optimization
as well.  In this usage area of SAML (PDP-PEP), fundamentally we are
defining a protocol over which we can securely transmit information about
whether a user is authorized to do "something".    "Something" can, for
example, be access a web page, access an XML/SOAP service, or be a party to
a transaction.  We have the term "resource" to define that "something"
today.  In my opinion, what the discussions about (filesystems and
wildcards) and REGEX and (target/action) are about is really how to describe
the thing that is the point of the authorization question - can a user do
"something".  We want to use these more detailed ways of describing
"something" in order to perform optimizations to the protocol - optimizing
performance and/or perhaps interoperability.  With web resources the
filesystem/widcard optimization seems to makes sense, with an XML service
the target/action (perhaps), with the transaction it isn't clear, and REGEX
works good for all of them but is tough from an implementation performance
standpoint.  

These optimizations will require the systems which are acting as the actual
PEPs to implement (or at least map to) what is essentailly a datamodel
described by the optimization.  It will also require that PDPs follow these
new datamodels/datatructures (filesystem/wildcarding or target/action) or
they will have no way.  I believe these factors will work against adoption
of the standard because implementors will find it difficult to map their own
datastructures to the standard.  For example, if we are asking a database
company to use these assertions for it's access control, it would be
difficult to leverage any of these (filesystem/wildcarding, target/action,
or REGEX).  This is especially true for COTS applications like PeopleSoft.
The resources these apps protect are structured very differently, and so are
the permissions on them.  So it will be very difficult to come up with an
optimization which is useful across all implementations.

I think that if there is going to be a general way to model resources, then
that work should be done in XACML b/c is it so squarely in their domain -
it's hard to define an access control policy without defining a resource.  I
don't think that whatever resource modelling we would do will be useful
enough for them, and therefore we would probably have a redundant effort
with them.  I think trying to define all of these optimizations here would
be a big schedule hit and a mistake.  Primarily because I don't believe it
will be easily completed and SAML already has considerable schedule
pressure.  Secondarily because the systems on either end will need to be
able to map this policy to their local datastructures and domain models, and
so a general solution will have limited usefulness (unless we take a
significant amount of time to get it right).

So after I railed against it for so long, I feel I need to provide a
suggestion about what we should do.    I think the resource definition
should be a string that is sent by the PEP to the PDP when it needs to make
a decision.  The relationships between the strings and the resources they
represent are set up 'out of band'.  In other words, we should leave it up
to the PEP to decide how they want to ask the question, and when the policy
is configured on the PDP, it is created to handle the PDP's questions.  For
example:

<SAMLAuthZRequest>
   <RequestID>urn:random:a0jt498u29jgoijrep98sj454aw
   <Subject>Alice
   <SubjectDomain>bizex.com
   <Resource>http://store.carol.test/finance

... with a response like ...

<SAMLAuthZResponse>
   <RequestID>urn:random:a0jt498u29jgoijrep98sj454aw
   <Decision>Allow
   <Validity>

... and for an optimization perhaps ...

<SAMLAuthZResponse>
   <RequestID>urn:random:a0jt498u29jgoijrep98sj454aw
   <Decision>Allow
   <Validity>
   <Advice> (XACML-defined policy which is relevant to the request)

I think I can be convinced that another way to make the request so that it
may be more useful in the XMLP/SOAP world with a target/action optimization,
where the response looks the same, but the request changes to:

<SAMLAuthZRequest>
   <RequestID>urn:random:a0jt498u29jgoijrep98sj454aw
   <Subject>Alice
   <SubjectDomain>bizex.com
   <Resource>http://store.carol.test/finance
   <Action>access

... although I should say that I don't know much about SOAP.  

Regards,

Darren	



> -----Original Message-----
> From: Simon Y. Blackwell [mailto:sblackwell@psoom.com]
> Sent: Tuesday, May 15, 2001 5:48 PM
> To: 'Platt, Darren'; security-services@lists.oasis-open.org;
> 'xacml@lists.oasis-open.org'
> 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
> > 
>