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 filtere dgetDescription()

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.


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

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

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