RE: [wsrp-wsia] Roles

[Maryann Hondo <mhondo@us.ibm.com>]

All,
I've just joined this mailing list so I'm rather new to these exchanges and
may be dropping into the middle of something.

From a security perspective it is always safer to stick to a simple model
or one that has been vetted previously by the security community.
I'm not convinced that keeping a string  which indicates the name of a
"role"  which  can't be proven is of much use in
particular because (in my understanding) WSRP has a delegation model where
the consumer is asserting a role on behalf of the end user which
the end user may or may not know about.  So I would recommend leaving
"roles" out of the spec and concentrate on
following the web services paradigm of using wsdl  and soap headers
(WS-Security) to provide authentication/authorization
assertions(SAML, XRML, XACML) on messages or transport protocols (
HTTPS/SSL/TLS) where these are appropriate (SSL is point to point and I
have some concern about how you expect this to work in a model in which a
consumer is an intermediary and there are other user agents...SAML spent
quite a bit of time on this issue).  There are also discussions in the
WS-Security group on QOP and a new set of input documents from a set of
industry participants on WS-Policy, WS-Trust and WS-Secure Conversation
which can also be leveraged by web services and may be of use to WSRP ( of
particular interest might be the WS-Policy Attachment spec which asserts a
model for adding metadata to a wsdl description).

It is unfortunate that your spec or primer does not really address either
the delegation model or a security model in general.  Interspersed
through the spec and the primer ( I just got through the primer and  have
done one pass on the spec but there is a lot I still don't understand) are
references to pieces of security technology ( SSL, etc)  and other
technology (cookies) which are known to introduce security and privacy
problems,
without any real discussion of where and how these technologies should be
used. The biggest problem in providing secure
solutions is not depending on crypto to make something secure.....it is the
implementation details where the vulnerabilities appear.
I would suggest that you try to get some security review of and input to
the primer. ( Is there a scenarios document at all?)
I don't  see how you will be able to support secure interoperable WSRP
implementations, but I guess you see that
as out of scope for this spec, or maybe I'm just ignorant of how you see
this being implemented.
Where do you expect that this type of evaluation will happen? It is
unfortunate that OASIS doesn't have a mechanism
for formally evaluating how different specs (like WSRP, WS-Security and
SAML) may or may not work together.
It may only be through profiling with a group like WS-I that this may be
attempted.  Another alternative would be to ASK the
WS-Security or SAML group or OASIS for a liaison to be established between
the two groups.

Also, when will a version of the spec with the new changes (like
userCategory) be available for review?
It's difficult to follow all the proposed resolutions of these issues.


Maryann Hondo

so here's the comments of a WSRP newbie....(See attached file:
primer-mh.pdf)




Carsten Leue <CLEUE@de.ibm.com> on 01/08/2003 07:39:17 AM

To:    Monica Martin <mmartin@certivo.net>
cc:    Rich Thompson/Watson/IBM@IBMUS, wsrp-wsia@lists.oasis-open.org
Subject:    RE: [wsrp-wsia] Roles



From my understanding we separated out the tow issued now in our last call.
We only kept the personalization aspect and call it userCategory now.

Please correct me if I am wrong.


Best regards
Carsten Leue

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




             Monica Martin
             <mmartin@certivo.
             net>                                                       To
                                       Rich Thompson/Watson/IBM@IBMUS,
             01/02/2003 08:05          wsrp-wsia@lists.oasis-open.org
             PM                                                         cc

                                                                   Subject
                                       RE: [wsrp-wsia] Roles










On Roles, can we separate the personalization for roles and those
related to security (Presentation, access and privileges may overlap
here)?

Monica

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Thursday, January 02, 2003 7:48 AM
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>




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: =?ISO-8859-1?Q?primer-mh=2Epdf?=
Description: Adobe PDF document