[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Dealing with unauthenticated users
My apologies. I mean "not authenticated". A consumer may "know" the identity of the user and choose to pass this information on even though this identity is not authenticated. So again I don't believe userAuthentication=wsrp:none says anything about the consumer knowing the user identity -- just whether it is authenticated or not. -Mike- Subbu Allamaraju wrote: > I'm a but puzzled by your point that userAuthentication=wsrp:none > means the user is not "authorized". This has nothing to do with > authorization. It just means that the consumer has not yet or could > not determine the user identity. The consumer may still send some user > categories that the producer *may* use to personalize the markup. Why > would this not address your use case? > > Subbu > > 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 >>>> >>>> >>>> >>>> *Michael Freedman <Michael.Freedman@oracle.com>* >>>> >>>> 07/15/2003 03:27 PM >>>> >>>> To: wsrp-interop >>>> <wsrp-interop@lists.oasis-open.org> >>>> cc: WSRP <wsrp@lists.oasis-open.org> >>>> Subject: [wsrp] Dealing with unauthenticated users >>>> >>>> >>>> >>>> >>>> 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]