[wsrp-wsia] Change request #138: Transferring UserContext to proxiedresources

[Michael Freedman <Michael.Freedman@oracle.com>]

This note is intended to both motivate the change request and to propose 
a solution that the few who stayed after school on this mornings 
conference call reached consensus on.

Motivation for this change request:
JSR 168 defines the concept of a portlet application.  A portlet 
application is a set of portlets [akin to our producer] + the set of web 
resources accessed/rendered by the application during usage.  These web 
resources can be either static or dynamic.  When dynamic they are 
expected to be servlets or derived from them.  I.e. web resources are 
accessed via http.  

JSR 168 requires that dynamic web resources running in the context of 
the portlet application be presented with the same information as to who 
the request user is and what roles this user has.  JSR 168 permits 
portals to provide this information to the portlet rather then requiring 
it be established and maintained by the J2EE security system.  I.e. JSR 
168 sees as valid and useful the ability of the portal in conjunction 
with the JSR 168 portlet container to use the WSRP UserContext to 
satisfy the requirement of  providing a uniform representation of the 
user and its roles/categories to both the portlets and its web resources 
in a portlet application.

The change request I opened observed WSRP didn't define sufficient 
mechanism to ensure this UserContext could be passed when appropriate to 
the proxied resource and suggested we address this.  To date, there have 
been 4 types of solutions offered:
        a) rely on the producer to maintain this information in 
[session] state.  I.e. as JSR 168 assumes the web resource and portlet 
run in the same session context then problem is solved if the JSR 168 
container merely "caches" the needed information in its session.  The 
problem with this solution is its overly restrictive.  It requires the 
JSR container to be session based merely to satisfy the JSR requirement. 
 This essentially denies stateless portlets in a JSR 168 container with 
the corresponding loss of load balanced scalability.  Basiaclly, the 
problem with this approach is one of completeness.  Though it is a 
correct technical solution it doesn't cover all our use case.  Therefore 
additional mechanism needs to be supplied to handle the non-session 
case.  The following three scenarios attempt to address this other 
situation.
        b) require the producer encode this information directly into 
the proxy resource URL.  The problem with this solution is that these 
URLs ultimately get back to the client.  There would likely be 
significant privacy/security concerns with being able to see this 
information in plain text in a client.  Though encryption techniques 
could be used you potentially run into URL length issues.
       c) define a mechanism whereby the portlet/producer can request 
the UserContext be sent to the proxy resource by encoding this desire in 
the proxy resource URL.  I.e. as the portal has the UserContext 
information all we need to do is provide a token to the producer to 
include in its proxy resource URL that indicates the information should 
be added when the portal calls the proxied resource.  Defining such a 
mechanism requires we define a standard way this information be passed 
to the resource.  WSRP specific headers were suggested.  Though this 
solution satisfies the technical requirements we are trying to achieve 
here, concern has been expressed that we shouldn't be defining standard 
http usage in a web services environment.  

This leads to the fourth option which the group who talked after the 
meeting today reached consensus would be the best solution for version 
1.0.  
       d) require the portlet/producer [that isn't using the session 
solution mentioned in (a)] to encode the UserContext information in a 
cookie.  This cookie would be separate from any session cookie [if the 
later exists].  In addition, to make this work, we would require that 
those consumers dealing with cookies manage cookies for proxied 
resources in the following manner: consumers would pass to the proxied 
resources those cookies being maintained on behalf of the specific user 
of the specific portlet where the proxied resource is in the specific 
cookie's cookie domain.

Basically, the proposal for this change request is to NOT define any 
specific behavior related to what/how portal/portlet UserContext  
information is passed to proxied resources.  Rather, we merely 
extend/clarify the cookie support mechanism we already define to cover 
proxied resources.  And we will then rely on producers to leverage this 
cookie mechanism [for the time being] to address its data transport 
issues.  As we discussed extending the cookie support mechanism pretty 
thoroughly 2 weeks ago and at that time reached a point of consensus 
that adding such support was okay my hope is we can close this change 
request quickly.  I.e. I propose we formally adopt extending the cookie 
support semantics to cover proxy resources as discussed here and on the 
call 2 weeks ago and then leave the UserContext data management as an 
exercise for the producer/JSR 168 container developer.
      -Mike-


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>