Title:
yes,
agree that would be a valid approach.
-----Original Message-----
From: Alejandro Abdelnur
[mailto:]
Sent: 17 July 2003
17:46
To: WSRP OASIS
Subject: Re: [wsrp] Dealing with
unauthenticated users
Then they are not unidentified users, they were all given the same user ID.
For the purposes of the consumer are the same user. For example, the consumer
could select this shared userID based on the IP address of the user agent. In
this case userAuth would have a value like 'IPaddress'.
Alejandro
On Thursday, July 17, 2003, at 12:53 AM, Andre Kramer wrote:
Even unidentified users (authenticated but
sharing some login) will belong to some security grouping/principle. This
can be the basis for identity management.
In the end, consumers and producers will
need real security protocols to communicate security information and policy
(such as: authenticated but not a unique principal <-> guest).
Meanwhile, consumers can do simple
assertions of authentication method, user profile and user categories,
but I would not start reading too much into these. I was only trying to point
out that we have the possibility to use userAuthentication (may be wsrp:none)
and userProfile (may be nil) and should not try to give a low level data base
key (userContextKey which must not be null) additional meaning.
regards,
Andre
-----Original Message-----
From: Michael Freedman
[mailto:]
Sent: 17 July 2003 01:44
To:
Subject: Re: [wsrp]
Dealing with unauthenticated users
Again, sorry for the confusion using the word authorization when I meant
authentication. Anyway, why isn't it valid in scenario 2 for the
consumer to send a user identity even though the consumer hasn't authenticated
the user -- userAuth = none? I believe it is both valid and useful --
hence a consumer won't act like (1) -- it will send a valid userContextKey.
-Mike-
Alejandro Abdelnur wrote:
I would echo Subbu here,
WSRP1.0/Page 27, "• userAuthentication: String indicating how the End-User
was authenticated."
RuntimeContext.userAuthentication indicates the form of 'authentication'
the user has used with the consumer. It has nothing to do with
'authorization', that normally handled by the roles the user has.
So there are three possibilities here:
1* The user has authenticated with the consumer
userAuthentication=wsrp:none
2* The user has authenticated with the consumer but the consumer has chosen
not pass the information to the producer
userAuthentication=wsrp:none
3* The user has authenticated with the consumer and the consumer indicates
the mechanism used for this authentication
userAuthentication=wsrp:password|wsrp:certificate|<OTHER_AUTH_METHOD>
If you are mapping userCategories to JSR168 roles then you have to keep the
following in mind: if the user is not authenticated the user can not have
roles. Servlet/EJB/Portlet specifications do not allow roles if the user is
not authenticated. And the behavior for the three possibilities would be:
On #1:
userContextKey and userCategories are null.
On #2:
If the consumer is hiding the fact the user is authenticated from the
producer. So for the producer it would be identical as case #1.
On #3:
userContextKey as a consumer defined value
userCategories may have values
If you are not mapping userCategories to JSR168 roles then the identity and
roles of the user would be passed through extensions, but you could still
indicated the authentication type in RuntimeContext.userAuthentication
element.
And, going to your specific concern, you could use a a
'com:oracle:auth:weak' string to signal weak authentication, then you could
pass userCategories (and map them to roles in the JSR168 implementation).
Alejandro
For the first one userCategories wouldd
On Wednesday, July 16, 2003, at 11:26 AM, 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:]
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
<image.tiff>
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
