[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][security] High-level scenario
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC