OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [wsrp][security] Agenda for 5/1 telecon: User Profile

Mark, Yossi,

these indeed are topics that need to be discussed in the interfaces group.
I am not sure whether these details need to be defined before the security
group can proceed.

Regarding instances and user profile and other details of the WSRP
protocol, WSRP's use of security should only make minimal assumptions. As
far as possible, security should treated as an orthonal aspect, not
something tightly tied into the WSRP protocol.

Look at some of the most urgent things to address from a security
persective, I can imagine an approach that is agnostic of dmany etails of
the WSRP protocol. Just for example, we could define something like

Confidentiality of communication between a WSRP Consumer and Producer may
be achieved by the infrastructure running a WSRP service, e.g. by using SSL
or TLS for echanging SOAP messages. The information on whether or not a
service requires confidentiality is defined in the meta information of the

Authentication of Consumers
Authentication of consumers may be performed by SSL/TLS client
authentication, HTTP basic auth etc by the infrastructure running a WSRP
The information on whether or not a service requires authentication of
consumers is defined in the meta information of the service

Authorization of consumers using WSRP services may be achieved by the
infrastructure running the service by using the identity of the consumer
obtained during prior authentication and using internal information to
determine whether that consumer should have access to a particular service.
Authorization of consumers is not externally visible and has no impact on
the meta information of the service.

Identification of Users
WSRP consumers may transfer user identity and user profile information with
calls to WSRP services. WSRP services may use this information to identify

Authentication of Users
WSRP services may trust the user authentication that has been done by the
consumer and rely on the user identity information passed by the consumer.
WSRP services that don't trust authentication by the consumer may require
the user to provide credentials (e.g. user id and password specific to the
service) through their UI presentation. This may happen through the normal
processAction/getMarkup user interaction mediated by the consumer if the
service trusts the consumer.

The only assumption about the WSRP protocol made here is that the consumer
provides user identity information in the requests to the service.

Whether instances are created on behalf of consumers or users of consumers
should be impacting the security mechanisms.

Best regards,


"Tamari, Yossi" <yossi.tamari@sapportals.com> on 04/30/2002 07:05:52 PM

Please respond to "Tamari, Yossi" <yossi.tamari@sapportals.com>

To:    "'Cassidy, Mark'" <mcassidy@Netegrity.com>,
       "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>
Subject:    RE: [wsrp][security] Agenda for 5/1 telecon:  User Profile

Hi mark,

I really think that these are issues that should be discussed by the
interfaces sub-committee (everyone). These are not security issues, even
though they certainly have a huge effect on the security requirements.
It seems to me that as the security sub committee should raise these
questions urgently in the interfaces discussions, since not solving them is
holding us back.


-----Original Message-----
From: Cassidy, Mark [mailto:mcassidy@Netegrity.com]
Sent: Tuesday, April 30, 2002 7:51 PM
To: 'wsrp@lists.oasis-open.org'
Subject: [wsrp][security] Agenda for 5/1 telecon: User Profile

> I'd like to focus discussion in tomorrow's call on the issue of user
> profile.  There seems to be different ideas about what personalization
> means and how it relates to user profile.
> Take the runtime flow of a portlet computing the markup it returns to the
> portal:  the portlet requires a number of parameters to be defined in
> order to generate the markup it returns to the portal.  Some of these
> parameters may be explicitly associated with the portlet instance and
> stored with the persistent data for that instance.  Other parameters may
> be obtained from someplace else, such as user profile, where that data
> be shared by other portlets or used for other functions within the
> Another twist to this is that it is not uncommon for portals to support
> the notion of a portlet parameter value which is scoped to a group.
> The logic that drives assembling all the parameters needed by a portlet
> generate it's markup needs to be clear.
> A couple questions to get some discussion going on the forum prior to the
> meeting:
> 1.  Should a portlet instance be scoped to individual users, with all
> parameters fully specified, such that a given instance always returns the
> same markup?  Or should an instance represent a partial parameterization
> of a portlet service(one step more fully specified than the portlet
> template), where the remainder of user-specific parameter values needed
> are fetched at runtime from some source outside the portlet instance?
> Another scenario might be that *all* users' parameterizations would be
> maintained with the instance data; in this case, the runtime invocation
> would require both an instance handle and some type of user handle.  My
> own opinion on this is that each instance should correspond to a fully
> enumerated parameter set, where a unique instance handle would exist for
> each user's personalized configuration of the portlet.
> 2.  If not all the parameter values are stored with the instance, what
> mechanisms should be supported for assembling the full parameter set at
> runtime?  How is this divided between portal and portlet?  A user profile
> would logically fall under this mechanism.
> I'm going to be offsite for the remainder of the day today and will be
> back on email later tonight to followup on any discussion around these
> points.
> Logistics:
> Time:  Wednesday, 5/1;  8:00 a.m. PST(11:00 a.m. EST, 6:00 p.m. CET)
> U.S. Phone:   877.450.3529
> International phone:  +1.706.679.6653
> Conference Code: 4254672722

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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC