Just to reopen the role discussion: instead of thinking of refining the
role support we should think of dropping it altogether. I summarized the
reasons for this already in another email.
One example reoccurs in Eilon's example - the producer that spans multiple
web-apps in J2EE. For me this seems to apply that the producer would use
the app's J2EE roles as WSRP roles. In this case I would also assume that
after a WSRP call containing such role information a call like isUserInRole
would work on the producer. However as no credentials are sent around this
is impossible to implement.
From my point of view it would be best to rely on WS-Security.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
Gil Tayar
<Gil.Tayar@webcol
lage.com> To
12/10/2002 09:18 cc
AM
Subject
[wsrp-wsia] [I#175] Roles should be
per-Entity and not per-Producer
Issue: 175
Status: Active
Topic: interface
Class: Technical
Raised by: Eilon Reshef
Title: Roles should be per-Entity and not per-Producer
Date Added: 10-Dec-2002
Document Section: v0.85/4.1.7
Description:
RoleDescription[] - should it be per each Entity and not per Producer? The
current model only supports roles per Producer which works when the
Producer is a centralized portal environment, but makes it much harder to
manage and deploy changes in less controlled environment. For example, this
means that if a development environment allows portlet developers to define
custom roles per portlet (e.g., if one Producer may span multiple web-apps
in J2EE), then the Producer must continuously accumulate all roles from all
its portlets to present a coherent role list. And, the Consumer needs to
sample that list more often to ensure that there are no changes. Another
example is how would an application-level-WSRP-proxy support multiple
services with different roles?
