[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] [wsrp][intefaces] Use case for userfilteredgetDescription()
No, that is not what I'm suggesting. I'm just saying that it isn't clear where in the protocol this information is going to be put into play. The single-sign identification authentication and certification is one process, the specific permissions allowed to an inidividual for our purposes, is an add-on to that. The point at which the Consumer gets that information is the concern of this scenario. Like I said, I can envision a case where an end user might not want to allow the Consumer to know ALL of the permissions a Producer allows--say in a situation where the Director of HR will have access to all of a company's personnel files, but at home or on the road, the Director wants to compare benefit policies from a several competitors from the viewpoint of a potential employee he is evaluating. If he goes to a Web Service (A Consumer to us) to get the information about different benefit packages for competing companies as well as his own, his name and ID authentication give him access to a great deal of material from his own company's portlets that is not supposed to be public knowledge. Presumably the Consumer being used to compile the portlets from competing companies would get that information. I have now done the thing that drives me nuts--working on designs by trying to find exceptions. However, I am not suggesting we disallow the Consumer from getDescription in this case, but I would keep an eye on it to see if it turns up enough such cases that it needs to be amended in v.2 Ciao, Rex At 10:57 AM -0700 8/13/02, Michael Freedman wrote: >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> > > >---------------------------------------------------------------- >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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC