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: Re: [wsrp-interfaces] [wsrp][intefaces] Use case for user filteredgetDescription()

    My answers to your questions ...

1. Portlet permissions are based on "authorization" ID?  This is either the user ID or a role.  I thought our discussions in the security subcommittee represented/passed both of these.

2. Yes, the consumer would make the call on demand.  Yes, this could potentially be a heavy load.  In practice however it is not as users don't frequently access the toolbox (compared to utilizing the portal pages).  And in any case there is no requirement a consumer
implement such function (or utilize this version of the call).

3. Yes, for this scenario it means "can the user put this portlet on a page"?  Basically, this is the age-old UI question of "should a user be visually presented with something they can't do."  The argument is that some producers will include various entities that are
segmented by user/roles.  Though the consumer has a "protection" mechanism we have acknowledge that producers can have additional levels of authorization.  This is one type of producer authorization check that currently isn't accounted for in the protocol.  As we
accounts for others, I suggest we also account for this one.


"Tamari, Yossi" wrote:

> This raises some problems:
> 1. Are the portlet permissions based on a user ID? I did not think in the general case user IDs were transparent to the producer. The permissions are role base as far as we talked in the security sub-committee.
> 2. Users permissions at the portlet can change at any time. Does the consumer call getDescription for all consumed portlets each time a user opens the toolbox? This could create quite a heavy load.
> 3. What does it mean "entities that this user has access to"? even assuming we pass all the roles of the user, the portlets have multiple modes. A user may be allowed to use one mode but not another. Does this mean he is not allowed to put the portlet on his page?
> Considering that the consumer already has its own set of permissions, and that I believe most producer will not have per-user /role permissions at least in the beginning, I would suggest we defer this.
>         Yossi.
> -----Original Message-----
> From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> Sent: Friday, August 09, 2002 2:00 AM
> To: interfaces; wsrp-wsia
> Subject: [wsrp-interfaces] [wsrp][intefaces] Use case for user filtered
> getDescription()
> 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>
> ----------------------------------------------------------------
> 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