wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Dealing with unauthenticated users
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Wed, 16 Jul 2003 15:06:55 -0400
I would agree, though think we may want
to consider additional values for userAuthentication for v1.1
Rich Thompson
| Subbu Allamaraju <subbu@bea.com>
07/16/2003 03:00 PM
|
To:
Michael Freedman <Michael.Freedman@oracle.com>
cc:
wsrp@lists.oasis-open.org
Subject:
Re: [wsrp] Dealing with unauthenticated
users |
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]