Re: [wsrp-wsia] [change request #138] Transferring information toproxied resources

[Rich Thompson <richt2@us.ibm.com>]

I agree that the cookie specification, in particular cookie domains, is 
sufficient in this area. I was reacting to a general impression that all 
cookies would be sent to resources.

My comment about predeciding is related to deciding to always send some 
particular set of information to the resource. Mechanisms for sharing 
information that place the control for what is shared in the hands of the 
Portlet developer already exist. Prime examples include cookies, 
url-encoded information and URIs. These should be exploited by the Portlet 
and Resource rather than new ones invented.

My suggestion is that our guidance be of the form that some information is 
sensitive (e.g. security or privacy reasons) and therefore should not 
travel by such indirect means as cookies or url-encoding. In these cases, 
passing a URI for accessing the information is preferred and provide the 
Portlet the ability to separately validate access to the information 
should be allowed (e.g. identity used for the Resource's request of the 
information).

Rich Thompson




Michael Freedman <Michael.Freedman@oracle.com>
02/18/2003 06:09 PM
 
        To:     wsrp-wsia@lists.oasis-open.org
        cc: 
        Subject:        Re: [wsrp-wsia] [change request #138] Transferring 
information to proxied resources


Rich,
    Don't you think the cookie specification [in particular "cookie 
domains"] is sufficient to handle security and privacy concerns?  I.e. 
the consumer only offers cookies to proxied resources that are in the 
same cookie domain.  Wouldn't this also negate the "predeciding" issue 
in that the portlet explicitly decides what/whether a cookie is sent to 
a resource based on how strictly it sets the cookie domain?
     -Mike-

Rich Thompson wrote:

>I think there are security and privacy reasons why we might not want to 
>send a portlet's set of cookies to a resource. We also should not depend 
>on cookies for transferring such information. I would argue against 
>predeciding what information might  be useful to such a resource. I also 
>would not want to design for v1 how a Portlet could specify to the 
>Consumer the various pieces of information that should be transferred in 
>any of several techniques. I would prefer giving guidance for how 
>cooperating portlets/resources can transfer how to connect to the 
>information at the Portlet (logically a URI) via a URL parameter.
>
>Rich Thompson
>
>
>
>
>Andre Kramer <andre.kramer@eu.citrix.com>
>02/14/2003 04:17 AM
> 
>        To:     "'Michael Freedman'" <Michael.Freedman@oracle.com>, 
>wsrp-wsia@lists.oasis-open.org
>        cc: 
>        Subject:        RE: [wsrp-wsia] [change request #138] 
Transferring 
>information to  proxied resources
>
>
>Mike, see comments below. Hope I understood all your questions.
> 
>regards,
>Andre
> -----Original Message-----
>From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
>Sent: 13 February 2003 19:58
>To: wsrp-wsia@lists.oasis-open.org
>Subject: Re: [wsrp-wsia] [change request #138] Transferring information 
to 
>proxied resources
>
>There are a couple of problems with what you suggest:
>      a) cookies use isn't limited to session identification.  Cookies 
are 
>also used to hold state rather then ids.
>[Andre Kramer] The WS-I basic profile says that cookies must be opaque to 

>the consumer so they really are more likely ids if we conform.
> 
>      b) if you are suggesting that the producer only URL encode the 
>session when using a resourceURL then the solution suffers from not being 

>able to restablish a session that timeouts before the resource is 
>activated.  Basically, J2EE doesn't prevent you from carrying the session 

>ID in both cookies and URLs -- it isn't designed that way -- rather its 
>designed to work using one method or the other consistently. 
>[Andre Kramer]  Yes, resource URLs for timed out sessions would fail to 
>get the session data. We are back in the Web world. One can configure 
>session timeout to be something sensible?
>
>      c) if you are suggesting the producer session encode via the URL 
vs. 
>cookies for all support then the solution suffers from not being able to 
>establish the ID in a load balanced environment.  WSRP only provides such 

>support for cookies.
>[Andre Kramer] No, hope I'm not. But one can session encode the *same* id 

>as carried in the JSESSIONID cookie. Note, this is not encodeURL from the 

>Servlet API, only something like it.
>
>As for your suggestion that the producer has access to the userContext 
and 
>Template data via the session I see a couple of problems:
>      a) first, I added this change request for those portlets that don't 

>use sessions [i.e. are stateless].  We shouldn't require a portlet use 
>sessions merely to attain access to this information as we don't in our 
>regular interactions.
>[Andre Kramer] In my opinion, the case where there is no producer session 

>and the producer has not indicated templatesStoredInSession is outside of 

>our wsrp spec. Just normal Web URLs & resources.
>
>      b) second, doesn't the "I store this information in session" 
pertain 
>to the portlet session not the producer/cookie session?  I recall we 
>discussed at one point that a conequence of optimizing the producer so 
>that it used cookie session INSTEAD of portlet sessions is that such 
>information wouldn't be cached [in session].  Did we change the meaning 
of 
>this to mean either the portlet session or the cookie session?  If not, 
>those producers coded run optimized in consumers wouldn't have access to 
>this information even if they used cookies/sessions.
>[Andre Kramer] At the f2f,  we added a invalidSession fault that allows a 

>http session based producer to require stached data be re-sent. [This was 

>missing even for Portlet sessions.] The commentary on invalidCookie also 
>asks a consumer to re-sent data so (hopefully sensible) consumers will 
not 
>get a double fault.
>
>       -Mike-
>
>Andre Kramer wrote:
>Do we really need to forward cookies from the consumer? The Servlet API 
>has
>a method to encode the session identifier in URLs (note: other means for
>tracking a session may be in place). Why not encode the JSESSIONID in the
>resource URL? Implementations can then convert this value to a cookie and
>forward the http request locally (producer side, with JSESSION cookie 
set,
>sort of like a reverse Web proxy).
>
>[This encodes a random identifier in the URL and so does not leak 
>sensitive
>information, if that was a concern.]
>
>We already have PortletDescription.userContextStoredInSession and
>PortletDescription.templatesStoredInSession so a producer already has all
>the machinery to:
>
>1) reference a session from a resource URL
>2) inject the session ID into the load balancing
>3) make sure the session is provisioned with WSRP data
>
>Therefore I don't think we need add anything. 
>
>Also, what about direct URL requests from the Web browser? Should they 
not
>be able to reference the producer session data also? The above scheme 
>would
>work for both Web user agent and consumer resource requests (and even
>re-directs).
>
>regards,
>Andre
>
>-----Original Message-----
>From: Rich Thompson [mailto:richt2@us.ibm.com]
>Sent: 12 February 2003 20:05
>To: wsrp-wsia@lists.oasis-open.org
>Subject: Re: [wsrp-wsia] [change request #138] Transferring information
>to proxied resources
>
>
>I think we can just extend this one, basically a new section between 10.3 

>and 10.4 with forward references from sections 10.2.1.1.4 and 10.2.2.7. 
>Something like "Using Resources".
>
>Rich Thompson
>
>
>
>
>Michael Freedman <Michael.Freedman@oracle.com>
>02/12/2003 01:47 PM
> 
>        To:     wsrp-wsia@lists.oasis-open.org
>        cc: 
>        Subject:        Re: [wsrp-wsia] [change request #138] 
Transferring 
>
>information to proxied resources
>
>
>I had already assumed that cookies had to be provided according to 
>cookie domain rules -- but yes its probably worth the clarification. 
> Also just remembered that in addition to this information we probably 
>need a way to transfer the rewrite templates to the resource as well so 
>it can generate new links that are proxied.  Can you just make a note to 
>extend this item or should I open a new one?
>     -Mike-
>
>Rich Thompson wrote:
>
> 
>Document: Spec
>Section:  10.3.3
>Page/Line: New section
>Requested by: Mike Freedman
>Old text:
>New text: New section describing how userContext/Profile information is 
>passed to resources.
>
>Reasoning:  Specification doesn't define how a portlet can transfer 
>userContext/Profile information to proxied resources.  As I don't recall 
>ever discussing it I want to find out if it should be left as is -- i.e. 
>an exercise for the portlet developer or we should define special http 
>headers to carry this information.  The problem with the former [current 
>model] is that this information will commonly be carried all the way back 

>to the client and appear in plain text in the browser URL -- folks may 
>freak seeing their UserId of personal profile information in a browser 
>URL.  If we define specific headers to carry this we not only make it 
>easy for the portlet developer as they don't have to encode/decode URLs 
but 
>also achieve more safety as this information is only represented between 
>the consumer and the producer.  Note: if we go this later route we will 
>probably want to add a boolean or two to the resourceURL 
>consumer/producer mechanism so they can control whether this information 
>needs to be past or  not [optimization].
>
>[RT] Good point on providing this type of guidance. There are significant 

>security and privacy issues in having this information appear either in 
>the URL or headers. Another alternative would be to suggest using an 
>indirection in the URL which allows the resource to locate the 
information 
>(likely an indication of the sessionID). This allows locating any 
>information the Portlet is willing to make available. Should we also 
>discuss whether cookies have to be connected back to the proxied resource 

>the same as to the Portlet?