RE: [wsrp-wsia] Roles

[Rex Brooks <rexb@starbourne.com>]

Per our discussion this morning, I suggest we consider renaming roles
in the contexts discussed as UserCategories or UserMemberships. I
also still think we ought to include a placeholder or disclaimer,
possibly in the registration process, if we keep it, where we
explicitly state that security standards will be required at
appropriate level for the WSRP information transaction taking place.

Ciao,
Rex

At 3:20 PM +0000 1/2/03, Andre Kramer wrote:
>I believe roles serve a much larger function than security (more than
>consumer access control) and are an integral concept in how a Portlet is
>rendered. If we remove roles than Producers will invent (mulitple) custom
>modes for their Portles to model in which dynamic logical role(s) a
>(consumer side) user is currently in and we are back at square one (not
>really having removed roles form our protocol). How about just renaming WSRP
>roles to "user or Portlet viewpoints" as a compromise? Then a consumer could
>chose to map real (consumer side) security roles to viewpoints and producers
>could police viewpoints using real security roles (if trust negotiated)?
>
>regards,
>Andre
>
>-----Original Message-----
>From: Rich Thompson [mailto:richt2@us.ibm.com]
>Sent: 02 January 2003 14:48
>To: wsrp-wsia@lists.oasis-open.org
>Subject: Re: [wsrp-wsia] Roles
>
>
>This posting has me concerned about scope creep for the specification.. I
>think the WSRP specification needs to define a protocol for how portals
>(generically Consumers) can interact with remotely hosted portlets through
>web service interfaces for the purpose of gathering and interacting with
>markup. We should be relying on other specifications to fill in the rest
>of what a full business will need and as much as possible be agnostic as
>to what those specifications are (e.g. WSRP should not depend on ip being
>the underlying transport protocol). Where holes are identified in these
>other specifications, we should be extremely careful about whether the
>WSRP protocol is the right place to invent solutions.
>
>My main argument is:
>  1) Roles are a security issue and there are specs for exchanging security
>information.
>  2) WSRP should be agnostic as to how security related information is
>exchanged between the Consumer and Producer.
>  3) If there are holes in the security specs (I'm not convinced there
>are), they and not WSRP are the right place for fixing those holes.
>
>Rich Thompson
>
>
>
>
>Rex Brooks <rexb@starbourne.com>
>01/01/2003 08:35 AM
>
>         To:     Carsten Leue <CLEUE@de.ibm.com>,
>wsrp-wsia@lists.oasis-open.org
>         cc:
>         Subject:        Re: [wsrp-wsia] Roles
>
>
>Thanks for the careful explanation of your viewpoint, Carsten, and
>Happy New Year to all.
>
>While I still disagree on the basis that Web Services are being put
>into service ahead of standards and will, regardless of standards,
>continue to do so until the marketplace enforces compliance, I have a
>better understanding of your reasoning.
>
>I also realize that my argument, that practice will produce many,
>possibly conflicting, usages and techniques, applies whether or not
>we specify a practice, even if it is essentially a placeholder in the
>WSRP spec that indicates where, in our process, the eventual standard
>for authentication of roles takes place.
>
>I mention that because, for me, that would satisfy my requirement
>that we not leave an open stage upon which any manner of process,
>(and remember that J2EE, which I also have to allow for btw, is but
>one among several) will be constructed and placed willy nilly
>anywhere near the start of a web service transaction in ways that
>will include and extend the problems you cite.
>
>So, in essence, my new argument is that including roles will serve to
>minimize the number of problems down the line that will arise between
>the release of v1.0 and v1.x, among which the ones you cite are the
>tip of as fairly large iceberg. To be honest, I would prefer to leave
>it out, because that is a cleaner solution, but the MAY makes it
>almost as optional as leaving it out would, except that it serves
>notice that we are making allowance for it.
>
>We might want to include a disclaimer to the effect that we intend to
>implement the standards of the WS-Security TC and the Joint Security
>Committee. That alternative would also satisfy my concerns that
>vendors not be allowed to act in the belief that they can cobble
>together anything that works with their current implementations.
>
>Ciao,
>Rex
>
>
>
>At 1:05 PM +0100 1/1/03, Carsten Leue wrote:
>>Hello WSRP fellows.
>>
>>I wish everybody a happy new year 2003!
>>In preparation of tomorrow's first WSRP call in 2003 here comes a summary
>>of my point of view regarding roles in WSRP:
>>
>>Proposal:
>>Leave every aspect related to roles out of the WSRP specification (and
>rely
>>on other standards instead, see below)
>>
>>Currently in the spec:
>>The Producer MAY advertize the roles it supports on a per entity basis.
>>These roles are non-localized strings. During a call to one of the
>methods
>>of the markup port-type the Consumer MAY pass a set of roles. The
>Producer
>>MAY trust this set of roles (e.g. because it has established a trust
>>relationship during registration) and may behave differently based on the
>>consumer's role assignment. It is important to note that the Producer has
>>no means to verify these role assignments but it must trust the Consumer.
>>
>>Why I think we should leave roles out:
>>1. The notion of roles has clearly a relation to security aspects because
>>the Producer could choose to use the role assignments to show/hide
>security
>>relevant information when generating markup (e.g. give more information
>to
>>admin roles). We already decided for all other security relevant parts to
>>rely on other existing or forthcoming standards (SSL, WS-Security)
>because
>>this greatly faciliates interoparability. We should do the same with
>roles
>>and wait until this problem is addressed by the WS-Security committee..
>>2. The idea that the consumer asserts a set of roles and the producer
>>trusts this assertion without checking again contradicts common WS
>security
>>paradigms. Both JSR109 (integration of WS in a J2EE environment) and the
>>WS-Security approach are different. They rather define how credentials
>flow
>>with a web services call. It is then the task of the Producer to validate
>>these credentials and assign roles based on these credentials. No further
>>trust relationship is required. I admit that the standard are silent on
>how
>>a probably necessary user mapping should take place, but this will be
>>addressed in the upcoming WS-federation spec.
>>3. Specific to a producer implementation on J2EE I furthermore see the
>>following problem in a JSR168 mapping: JSR168 does not define any role
>>concept but refers to J2EE roles. e.g. it assumes that isUserInRole works
>>from both a portlet and a possibly included servlet. There is no way to
>>explicitly access WSRP roles (although this could be done in a
>proprietary
>>way). Hence a J2EE implementation would need to make sure that WSRP roles
>>become J2EE roles. This however poses a problem. Normally it is the
>>application server that asserts roles and satisfies the isUserInRole call
>>based on credentials. In the WSRP case there are no credentials, the app
>>server is supposed to trust unsecured role information. As the
>isUserInRole
>>call cannot simply be overridden as it needs to work from EJBs and
>servlets
>>also, the app server core must be hacked to make role assignments without
>>credentials possible. This seems to be a very odd approach and makes the
>>standard impossible to implement for non-app server vendors. It also
>>compromizes the security policy of an app server.
>>4. What should happen if the consumer passes user credentials (e.g. in
>>conformance with JSR109) and in addition WSRP roles? The Producer's app
>>server would automatically assign the roles that correspond to the
>>credentials. What now if they conflict with the WSRP roles?
>  >
>>For me the arguments above point strongly in the direction of leaving
>roles
>>out.
>>
>>What could be done instead to achieve a similary behaviour is the
>>following:
>  >The Producer defines users that correspond to all possible (rather all
>>sensible) permutations of roles and advertizes these users' credentials
>>instead of the roles. The consumer then makes the WS call in behalf of
>one
>>of these users (very much like it works for EJBs now). The consumer makes
>>use of standard techniques to pass these credentials (e.g. basic auth or
>>WS-security). The producer can validate the credentials as they
>correspond
>>to a real user in its user subsystem and assign the corresponding (J2EE)
>>-roles automatically. The user profile key (as it is currently in the
>spec)
>>still exists and makes user awareness possible.
>>The advantage of this approach is that it completely relies on standard
>>techniques and works out of the box. The drawback is that you would need
>>one specific user for all role permutations.
>>
>>Best regards
>>Carsten Leue
>>
>>-------
>>Dr. Carsten Leue
>>Dept.8288, IBM Laboratory Böblingen , Germany
>>Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
>>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>--
>Rex Brooks
>Starbourne Communications Design
>1361-A Addison, Berkeley, CA 94702 *510-849-2309
>http://www.starbourne.com * rexb@starbourne.com
>
>
>----------------------------------------------------------------
>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>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com