[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 --------------- 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC