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

[Michael Freedman <Michael.Freedman@oracle.com>]

But I thought we already do include remote access control in WSRP?  I thought we had discussed allowing portlets to define roles that
consumers map -- and that user identity/role information is passed via the protocol so that the producer can do remote access control.
Is this correct?  If so I am merely suggesting another place in the protocol where exposing such a capabilities is useful.

As for WS-Authorization and other standards I am not sure if they are the best fit here.  Can you brief me on the standard and why/how
its the solution?  I worry that it is a web service standard whereas we need to do authorization at the entity level [which aren't web
services].  I can intuit that is might impact how the user/roles are communicated and basic producer authorization works but worry that
we would still need to define entity level authorization more explicitly.
     -Mike-

Carsten Leue wrote:

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