[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]