OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[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.

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