Re: [wsrp] Dealing with unauthenticated users

[Rich Thompson <richt2@us.ibm.com>]

The spec allows the Consumer two choices:
  1. Unidentified user => no
UserContext
  2. Identified user => UserContext
with a key to identify the user

Discussions in the Interop call today
decided that there is an important group of users whose identity is unknown
( proverbial guest user) where the Consumer still looks to assert a userCategory
of wsrp:minimal. We decided on a convention of using the value "wsrp:minimal"
for the userContextKey in this case. This effectively becomes a key to
a shared UserContext which only contains this key and the userCategory
wsrp:minimal.

Rich Thompson

Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM> Sent by: Alejandro.Abdelnur@Sun.COM 07/17/2003 12:46 PM

To:        WSRP OASIS <wsrp@lists.oasis-open.org>         cc:                 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:michael.freedman@oracle.com]
> Sent: 17 July 2003 01:44
> To: wsrp@lists.oasis-open.org
> 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: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
>
>
>
>
>
>