[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-interfaces] Re: [wsrp-wsia] [wsrp][intefaces] Use case for userfilteredgetDescription()
Are you suggesting that producers shouldn't be able to do any type of authorization check via our protocol? I believe, this is counter to what we have been discussing in the security subcommittee. The user ID I refer to is an "authorization" ID. I assume this is a user identifier and set of user roles. I believe we suggested this lives outside the profile. My scenario is based on the my understanding that we already support Producer level authorization -- hence I am merely suggesting one more operation [type] where producer authorization can be applied. My scenario [hopefully] shows a useful consumer use case [i.e. a better UI] for this. -Mike- Rex Brooks wrote: > This somewhat depends on whether the user wants the allow the > Consumer to have that information. I think the Consumer first has to > have permission from the end user explicitly. The end user may have a > contract with the Producer that she does not want to allow the > Consumer to know about. > > Assuming such permission, then it probably belongs to the user > profile. How and when that information is accessed is still somewhat > up in the air. I expect that this question will arise more once we > begin to get feedback from actual practice. I suspect that there will > need to be clearly visible disclaimers on Portal pages that make > these permissions clear, at least for the initial few sessions > between the end user and specfic Portals/WebServices. It hasn't been > clearly written into the protcol yet, and I am not sure that we > should attempt to deal with it yet. Partially it is the domain of > security in authentications and partially it is the domain of > practice--what works scalably with the least disruption yet fulfills > the legal requirements--and of course, the legal requirements will > evolve. > > I don't think we should attempt to specify this in this version. I > think we should let practice inform us of what we ought to do. > > Ciao, > Rex > > At 4:00 PM -0700 8/8/02, Michael Freedman wrote: > >During today's conference call I asked the question "Do we care about > >allowing the consumer to ask get me the description of all the entities > >that this user has access to?" I indicated our Portal has such a > >capability but wasn't sure if/how its used. After a little discussion we > >tabled the question pending having me report back with a use case (if > >any). This is our use case: > > In our portal when a user displays the portlet repository (toolbox) > >she is only shown those portlets she has access to. Though the bulk of > >this authorization is controlled via the Portal's authorization > >mechanisms we do provide a hook to the portlets authorization mechanism > >so it has an opportunity to decide. (i.e. only users in a given portlet > >role can add this to portlet to a page). > > > >Our requirement seems to be express in some way via the protocol a way > >to ask the question can this user access this portlet? For efficiency > >reasons it makes sense to expand this to what portlets can this user > >access? In our proprietary portlet protocol we chose to overload > >getDescription to accomplish this. Our getDescription takes an optional > >user which when present means only return me the information about those > >portlets this user can see. > > > >What we now need to answer are: > > a) is this a valid and useful usage scenario we should support in > >the protocol? > > b) if so, how should we support it? getDescription overload? Or > >should we have an isRunnable() type call (expecting of course these and > >other calls will ultimately be expanded to be [bulk] array based for > >efficiency? > > -Mike- > > > > > > > >---------------------------------------------------------------- > >To subscribe or unsubscribe from this elist use the subscription > >manager: <http://lists.oasis-open.org/ob/adm.pl> > > -- > Rex Brooks > Starbourne Communications Design > 1361-A Addison, Berkeley, CA 94702 *510-849-2309 > http://www.starbourne.com * rexb@starbourne.com > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC