Re: [wsrp-wsia] RE: [wsrp-interfaces] [wsrp][intefaces] Use case foruser filtere d getDescription()

[Carsten Leue <cleue@de.ibm.com>]

In my opinion we should not include remote access control in the WSRP
protocol.
- it seems to be orthogonal to WSRP and we will likely be able to leverage
upcoming standards as WS-Authorization. If we define this now it might be
to early.
- it adds too much complexity, especially if - as Yossi points out - the
access control rules might change over time


Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



|---------+---------------------------->
|         |           "Tamari, Yossi"  |
|         |           <yossi.tamari@sap|
|         |           .com>            |
|         |                            |
|         |           08/11/2002 11:42 |
|         |           AM               |
|---------+---------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                               |
  |       To:       "'Michael Freedman'" <Michael.Freedman@oracle.com>, interfaces <wsrp-interfaces@lists.oasis-open.org>,        |
  |        wsrp-wsia <wsrp-wsia@lists.oasis-open.org>                                                                             |
  |       cc:                                                                                                                     |
  |       Subject:  [wsrp-wsia] RE: [wsrp-interfaces] [wsrp][intefaces] Use case for user filtere       d getDescription()        |
  |                                                                                                                               |
  |                                                                                                                               |
  >-------------------------------------------------------------------------------------------------------------------------------|



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>