Title:
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:]
Sent: 15 July 2003
21:44
To:
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 <>
07/15/2003 03:27 PM
To: wsrp-interop <>
cc:
WSRP <>
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
