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: Thu, 17 Jul 2003 14:13:14 -0400
Categorizing is not equivalent to authenticating.
User categorizing can be via any ad hoc means desired. User authenticating
means applying a known algorithm (might only be known to yourself) to establish
the identity of the user. Users can certainly be categorized without their
identities being known (statisticians do it all the time).
Rich Thompson
| Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>
Sent by: Alejandro.Abdelnur@Sun.COM
07/17/2003 01:58 PM
|
To:
WSRP OASIS <wsrp@lists.oasis-open.org>
cc:
Subject:
Re: [wsrp] Dealing with unauthenticated
users |
My interpretation of what you are describing is that
the consumer is
doing some kind of authentication on the user, not necessary to
identify the particular subject. In that case, the userAuth should not
be null, but the kind of authentication the consumer is using to do the
classification.
Alejandro
On Thursday, July 17, 2003, at 10:32 AM, Subbu Allamaraju wrote:
> Alejandro Abdelnur wrote:
>> It is true that this is how Java technologies, such as
>> Servlets/EJBs/Portlets behave.
>> But I don't think that is 'Java specific'. IMO, that WSRP does
not
>> define a relationship betwen userAuthentication and the UserContext
>> is an underspecification on our part. But regardless of that,
if a
>> consumer indicates 'userAuth=none' is declaring, to the producer,
>> that the user is not authenticated in any form; if this is the
case,
>> why would you pass any userCategory, it's kind of meaningless,
all
>> non-authenticated users would have it.
>
> Why is it meaningless? The consumer may be able to categorize the
user
> based on, let's say, the user's interaction (the pages viewed, time
of
> the day etc.) even for anonymous users. The producer may then
> personalize the markup based on those categories.
>
> In the spec, we've made a conscious decision not to mix userContextkey
> and userCategories with authentication, and so it is valid for the
> consumer to categorize users irrespective of whether is user is
> authenticated with the consumer is not.
>
> Moreover, via the WSRP userAuthentication, the consumer is telling
the
> producer how the user was authenticated with the consumer. IMO, this
> is not related to the userContextKey and userCategories that the
> consumer is sending.
>
> Subbu
>
>
>> What was the reasoning on making userContextKey required and
>> non-nillable?
>> Alejandro
>> On Thursday, July 17, 2003, at 06:01 AM, Rich Thompson wrote:
>> I think this answer is a bit to Java specific. The
spec defines no
>> relationship between the userAuthentication field
and the fields
>> in
>> the UserContext structure. It is therefore quite
reasonable for a
>> Consumer to supply userAuthentication=wsrp:none
and a userCategory
>> value of wsrp:full. Now it is also quite reasonable
for the
>> Producer
>> to refuse to provide full access to an unauthenticated
user, but
>> this is an independent decision from whether the
Consumer prefers
>> them to have full access.
>> I would also note that userContextKey can not be
null as it is a
>> required and non-nillable field. The entire UserContext
can be nil
>> or the userContextKey can have some dummy value
(Mike's suggestion
>> was "" for his original question). I would
note that the spec
>> defines this field as:
>> "This key is a token that the Consumer supplies
to uniquely
>> identify
>> the UserContext. The userContextKey MUST remain
invariant for the
>> duration of a Consumer’s registration. The Producer
can use this
>> key
>> as a reference to the user.".
>> It is therefore reasonable for the Producer to use
this key as an
>> index into a cache of UserContext structures. The
result of this
>> is
>> that this key should only be the same for users
where the contents
>> of the UserContext match exactly (userCategories
and userProfile).
>> Rich Thompson
>> <image.tiff>
>> 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: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
>> >
>> >
>> <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
>> >
>> >
>> >
>> >
>
>
>
> 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]