OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] Dealing with unauthenticated users



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]