Title:
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
