RE: [wsrp][security] High-level scenario

["Tamari, Yossi" <yossi.tamari@sapportals.com>]

Three different scenarios seem to be emerging here, and I guess the
interface should support all of them:
1. Anonymous - The portal does not send any information about the user to
the portlet.
2. Identified - The user's ID (and probably some elements of his profile)
are sent to the portlet. This will enable the portlet to personalize its
content according to the user's profile, and in some cases perform
transactions for the user.
3. Authenticated - As 2, but in addition to the user's ID, his password is
also transferred. This is intended for the cases where the portal and the
portlet do not share the same users list, so it is not the portal password
that is transferred but a specific password for this portlet. This will
enable portals to implement a feature that allows the user to say: for this
portlet my ID is U and my password is P. This information can then be used
by the portlet to identify the user to some back-end transactive
application, for example.

Another comment about the "Two primary security issues to consider"
paragraph in the original document:
If the transport is HTTPS, there is no need for digitally signing the
document since (as far as I understand it) SSL supports client side
certificates. However, Web Services are not supposed to define the
transport, and I think we should support digitally signing the document,
either with the XMLDS or with the SOAP DS standard (optionally?) and not say
anything binding about the transport that is used (this is left to the
portlet and the portal to negotiate).  

      Yossi.

-----Original Message-----
From: Cassidy, Mark
To: 'PAVLIK,GREGORY (HP-NewJersey,ex2)'; 'wsrp@lists.oasis-open.org'
Sent: 03/04/02 01:11
Subject: RE: [wsrp][security] High-level scenario

Reauthenticating the end user was not the intent in this scenario.  The
important thing here is that the remote service does need to be able to
verify the identity of the *portal* that is proxying the request on
behalf
of the end user.  

Whether the end user's identity is included in the request is going to
be
driven by the requirements of the remote service(i.e. a role might be
passed
or some other attribute, not the identity of the end user).  I thought I
heard in the meeting that some vendors want to get this information.  I
would think it should be possible but not mandated.

Probably need to tweak some of the text in the scenario, but intent is
actually pretty aligned with the perspective conveyed by your comments.
Also, I expect that there are going to be a number of scenarios that our
constituents will be interested in.  This was just one example to get
the
discussion going.

-----Original Message-----
From: PAVLIK,GREGORY (HP-NewJersey,ex2) [mailto:gregory_pavlik@hp.com]
Sent: Tuesday, April 02, 2002 2:38 PM
To: 'wsrp@lists.oasis-open.org'
Subject: RE: [wsrp][security] High-level scenario


A couple of quick observations:

The text seems to imply an independent re-authentication of the user
within
the WSRP service infrastructure after the portal has authenticated the
user.
This is something that we will want to avoid if possible. For example,
the
WSRP service made have a trust relationship defined with respect to the
client asserting forward it's identity.

It's not clear to me that the portal should necessarily send the users
identity and the portal identity. Does this case simply imply that we
need
to support this but not mandate it? It's easy to imagine use cases where
where a business relationship between the portal provider and the WSRP
service provider is based on the two business entities independent of
the
client identity; in such cases, it's possible that the client, for
privacy
reasons, does not want to identified or tracked, or that the business
hosting the portal does not want individual users tracked.

Is this one of many scenarios that we'll be looking at?

Greg

-----Original Message-----
From: Cassidy, Mark [mailto:mcassidy@Netegrity.com]
Sent: Tuesday, April 02, 2002 3:42 PM
To: 'wsrp@lists.oasis-open.org'
Subject: [wsrp][security] High-level scenario


Please see the attached high-level scenario outlining security
considerations.  This is intended to be a seed for discussion in
tomorrow's
telecon; additional scenarios need to be identifed and then fleshed out
with
more details.  As was mentioned in today's joint wsia/wsrp interfaces
call,
we should be looking at other standards efforts in the security
space(SAML,
etc) and how they can address the needs we define in the WSRP context.
Ideally we could leverage those efforts and not need to invent anything
that
is specific to WSRP.

Comments?

 <<WSRP Security Scenario.doc>> 

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