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


I forgot to mention one problem with SSL: if the request is routed through
an intermediary, it will be able to see all the user information, and it may
than send it on unencrypted.

	Yossi.

-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Wednesday, May 01, 2002 5:45 PM
To: Tamari, Yossi
Cc: 'wsrp@lists.oasis-open.org'
Subject: RE: [wsrp][security] Agenda for 5/1 telecon: User Profile



Yossi,

I just realized that I had confused your first name and last name, sorry
for that.

I think we are at the core questions now:
Do we require partial encryption of messages in WSRP ?
If yes, do we require it for the 1.0 spec, specing out exactly which parts
of messsages may/should be encrypted under which circumstances ?
Or should this be addressed later, when the SOAP Security standards are
final and implemented in an interoperable manner for the different SOAP
stacks ?

I also think that secure transport should be optional. It should be
possible for services to specify whether they require secure transport and
for consumers to request secure transport.

I am not sure how big the performance difference is, usually the public key
operations in the handshake are expensive since they involve public key
operations, but the bulk encryption using the symetric block ciphers are
usually not that expensive unless the amounts of data are really large.
What other SSL related issues do you mean in particiular ?

Best regards,

Thomas



"Tamari, Yossi" <yossi.tamari@sapportals.com> on 05/01/2002 02:07:54 PM

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

To:    Thomas Schaeck/Germany/IBM@IBMDE
cc:    "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>
Subject:    RE: [wsrp][security] Agenda for 5/1 telecon: User Profile



It is exactly topics like signing and encrypting parts of messages that we
were discussing. The fact that it is not yet clear whether these things are
needed is exactly the problem - that's why we need to define the
interfaces.
I am not ignoring the existing (or future) protocol stack, but I do not
think that defining secure transport as a must for WSRP services is a good
direction. From my point of view, the security related parts of the stack
are standards like WS-DS, WS-encryption, WS-security etc.
(For example, if a portlet requires some profile field, we should not pass
it unencrypted. But on the other hand, if we use SSL for security here, the
whole request-response cycle has to be encrypted, affecting performance, as
well as some other SSL related issues. Instead, I would WS-encryption just
on the profile field and allow the rest of the data to flow throw HTTP, if
there are no other security issues.)

 Yossi.

-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Wednesday, May 01, 2002 2:55 PM
To: Tamari, Yossi
Cc: 'wsrp@lists.oasis-open.org'
Subject: RE: [wsrp][security] Agenda for 5/1 telecon: User Profile


Tamari,

this was just an example, not "my approach" - what I am saying is that the
goal should be that security in terms of authentication and connection
confidentiality and the WSRP protocol are orthogonal, so that WSRP may be
used together with different security mechanisms and WSRP should not
duplicate existing security mechanisms. We de-facto have a protocol stack
that is organized like

Application Layer

Security Layer

Transport Layer

which is in synch with what you typically find in the relevant Computer
Science Literature.

An example of a concrete instance of such a stack is

WSRP
SOAP
HTTP

SSL/TLS

TCP
IP

If WSRP on the application layer would ignore the already existing security
mechanisms at the lower levels of the stack and reinvent them, we would
create lots of problems.

Therefore, I think for authentication of consumers and conficentiality
between consumers and producers - for which well-established mechanisms
exist - we need to leverage the existing authentication and transport
security mechanisms like for example SSL / TLS. These are supported by
vitually all application servers in an interoperable way.

Above that, we need to investigate what requirements are not covered by the
existing mechanisms. Only if we come up with such additional requirements,
it would be a true reason for defining additional secutity mechanisms in
WSRP.

One thing for example that SSL/TLS dosen't cover is signing of individual
messages or parts of messages, non-repudiation, etc. However, it is not yet
clear whether these things are required...

Best regards,

Thomas


"Tamari, Yossi" <yossi.tamari@sapportals.com> on 05/01/2002 12:09:32 PM

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

To:    Thomas Schaeck/Germany/IBM@IBMDE
cc:    "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>
Subject:    RE: [wsrp][security] Agenda for 5/1 telecon: User Profile



Hi Thomas,

The problem with your approach is that in order to ignore the
implementation
of the interfaces, you relegate all the security issues to the transport
layer. However, we do not think this is enough. We think (I hope I am
correctly representing the rest of the subcommittee) that WSRP as an
standard should be secure regardless of the actual transport
implementation.
Secure transport can be used as an additional level of security, and to
encrypt the data itself (the markup of the portlet).

 Yossi.

-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Wednesday, May 01, 2002 12:46 PM
To: Tamari, Yossi
Cc: 'Cassidy, Mark'; 'wsrp@lists.oasis-open.org'
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
---------------
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
service.

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

Authorization
-------------
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
uers.

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,

Thomas




"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>
cc:
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.

 Yossi.

-----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
may
> be shared by other portlets or used for other functions within the
portal.
>
>
> 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
to
> 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>





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