[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