Re: [wsrp] Dealing with unauthenticated users

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

My apologies. I mean "not authenticated".  A consumer may "know" the 
identity of the user and choose to pass this information on even though 
this identity is not authenticated. So again I don't believe 
userAuthentication=wsrp:none says anything about the consumer knowing 
the user identity -- just whether it is authenticated or not.
      -Mike-

Subbu Allamaraju wrote:

> I'm a but puzzled by your point that userAuthentication=wsrp:none 
> means the user is not "authorized". This has nothing to do with 
> authorization. It just means that the consumer has not yet or could 
> not determine the user identity. The consumer may still send some user 
> categories that the producer *may* use to personalize the markup. Why 
> would this not address your use case?
>
> Subbu
>
> Michael Freedman wrote:
>
>> Unfortunately, RuntimeContext.userAuthentication=wsrp:none isn't good 
>> enough.  It doesn't mean that the user identity is undetermined.  If 
>> merely means the user wasn't authorized.  Some consumer may prefer to 
>> implement a form of "weak" authorization whereby they use a client 
>> cookie to infer who the user is prior to a formal login to present a 
>> [partially] customized page.  Weak authorization is represented by 
>> sending a UserContext with the userId and a 
>> RuntimeContext.userAuthentication=wsrp:none.  Hence we still have the 
>> issue I raised concerning recoginizing the difference between I don't 
>> know this users identity  but want to pass user categories that apply 
>> to unrecognized users vs. a real user identity.
>>      -Mike-
>>
>> Andre Kramer wrote:
>>
>>> We have RuntimeContext.userAuthentication == wsrp:none to say the 
>>> user identity is undetermined by a consumer.
>>>  
>>> Portlets can also use UserProfile info for users. If none is 
>>> supplied, the producer should not make any inference on user identity.
>>>  
>>> So I would prefer a real user context key and see no need on 
>>> agreeing a common value, but had asked for a "portlet is being 
>>> shared" flag to signal that a portlet is being multiplexed. Maybe 
>>> this expand to cover other common use cases in 2.0 such as "consumer 
>>> is hiding end user identity for privacy reasons"?
>>>  
>>> regards,
>>> Andre
>>>
>>>     -----Original Message-----
>>>     *From:* Michael Freedman [mailto:Michael.Freedman@oracle.com]
>>>     *Sent:* 15 July 2003 21:44
>>>     *To:* wsrp@lists.oasis-open.org
>>>     *Subject:* Re: [wsrp] Dealing with unauthenticated users
>>>
>>>     The wsrp list it is ...
>>>     I would like to avoid diving into the whole security discussion
>>>     again ... that is why at the end I tried [poorly] to distill the
>>>     question down to how can a consumer indicate that it provides user
>>>     categories for interactions where it doesn't know the identity of
>>>     the user?  Or put another way, how does the consumer provide
>>>     information to the producer so it can decide the consumers intent
>>>     on how an anonymous user can control the preferences of the
>>>     entity?  I don't think the consumer should manufacture [on its
>>>     own] a dummy user context key for this.  Rather it should have the
>>>     ability to clearly communicate this circumstance -- however, given
>>>     where we are in the specification process however we have to look
>>>     for ways of working within the structure we have -- hence I focus
>>>     on defining a consistent representation of this dummy user context
>>>     key so this particular situation can/will be represented in an
>>>     interoperable way.  I suggested "" to avoid collisions with any
>>>     name the consumer might consider valid in its environment.  
>>>          -Mike-
>>>
>>>     Rich Thompson wrote:
>>>
>>>>
>>>>     How about we just carry this thread on the wsrp list rather than
>>>>     many people getting duplicate emails?
>>>>
>>>>     I think there are some significant issues with interpreting
>>>>     application data items as supplying security information rather
>>>>     than actually using whatever might be available from security
>>>>     subsystems. While on the surface your suggestion might appear
>>>>     reasonable, how does it play out against the standard
>>>>     man-in-the-middle attack mode that security people work hard to
>>>>     stop?
>>>>
>>>>     Rich Thompson
>>>>
>>>>
>>>>
>>>>         *Michael Freedman <Michael.Freedman@oracle.com>*
>>>>
>>>>     07/15/2003 03:27 PM
>>>>
>>>>                            To:        wsrp-interop 
>>>> <wsrp-interop@lists.oasis-open.org>
>>>>             cc:        WSRP <wsrp@lists.oasis-open.org>
>>>>             Subject:        [wsrp] Dealing with unauthenticated users
>>>>
>>>>
>>>>
>>>>
>>>>     I have cc'd this e-mail to the entier list because I think folks
>>>>     might
>>>>     be interested in general -- I apologize up front if this is
>>>>     something
>>>>     you don't want to see.
>>>>
>>>>     We have discussed that though the specification doesn't define the
>>>>     UserContext [userContextKey and userCategories] as carrying 
>>>> security
>>>>     information, we expect some producers to use this application 
>>>> level
>>>>     information to satisfy its needs.  Currently, the userContextKey
>>>>     is a
>>>>     required field.  Hence the current way a consumer indicates it
>>>>     doesn't
>>>>     know the users identity is by passing a null userContext.  This
>>>>     however
>>>>     prevents the consumer from defining/mapping user categories to
>>>>     unauthenticated/unknown users.  However consumers often represent
>>>>     this
>>>>     class of user just so some control can be defined on this class.
>>>>      For
>>>>     example, control as represented by wsrp:minimal user category. 
>>>>     So the questions is, do we want to support defining/using user
>>>>     categories on public/guest users?  If so, how do we deal with the
>>>>     producer/JSR 168 interoperability problem wherein the producer
>>>>     uses the
>>>>     userContext/userContextKey field to establish whether its
>>>>     communicating
>>>>     with an authenticated user [through its trust relationship with 
>>>> the
>>>>     consumer]?  Wouldn't we need to define a special token value for
>>>>     userContextKey that all producers could safely use to mean the
>>>>     application hasn't established the identity of the user but oh by
>>>>     the
>>>>     way here are the user categories that relate to anyonymous 
>>>> users?  I
>>>>     would suggest we use the convention that an empty string "" as the
>>>>     userContextKey indicates such a user.  What do others think?
>>>>        -Mike-
>>>>
>>>>
>>>>     You may leave a Technical Committee at any time by visiting
>>>>     
>>>> http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php 
>>>>
>>>>
>>>>
>>>
>>
>
>
>
> You may leave a Technical Committee at any time by visiting 
> http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php 
>
>