Interoperability Minutes 2009-03-02

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-03-02

Contents

Attendees

  • Jon Ferraiolo, IBM
  • Matthias Hertel
  • Javier Pedemonte, IBM
  • Howard Weingram, TIBCO
  • Kris Vishwanathan, IBM
  • Rama Gurram, SAP

Original Agenda

Minutes

OpenID/SAML (single signon) authentication strategy

  • What is the general model here: widget responsibility or Hub responsibility?
  • Which approach(es) do we promote to widget developers who are using OpenID or SAML?
    • (a) Intermediary client hosts a nested IFRAME?
    • (b) Connected/reconnect within main widget IFRAME?

Jon: Lots of discussion lately in the Security TF about how to do single-signon, along with OpenID and SAML, in conjunction with Hub 1.1. We have talked about various proposals for how best to do it, and Javier has posted sample code in our open source project. As a general model, my thinking is that from the perspective of the Hub, it's the widget's responsibility. The Hub is just the pubsub engine.

Matthias: Completely agree. Moving to different domains is just putting something in an iframe that gets reloaded.

Rama: Only question, if you use OpenID, will each widget have to do its own authentication with the OpenID server or could they reuse one that has already been done?

Howard: I have an abstract conceptual model. Really a question of a mashup server and a gadget server, talking client-side over an insecure channel using the browser. User logs onto mashup server. Then mashup server and gadget server communicate with each other.

Jon: Do we need any new Hub features to support single signon, OpenID and SAML?

Howard: No

Rama: One widget authenticates OpenID. Easier to pass via Hub than connect to the Mashup Server.

Howard: What cares about the authentication is the Gadget Server. What's needed is passing a token from the Mashup Server to the Gadget Server.

Rama: That means each Gadgets server has to ... (support multiple authentication situations)...

Jon: How does the Mashup Server communicate with the Gadget Server?

Howard: We don't care, from the perspective of the Hub. Two ways to pass token, via a URL parameter or the Hub. Depends on how we approach redirection and reconnect.

Jon: So, this is all at a higher level than the Hub. For example, the widget level or the Manager Application level.

Howard: Yes. Hub is more concerned with loading and reconnecting. Probably more at the widget level. Probably need a standard way to pass a security token.

Kris: Makes sense to be at the app level. OpenID may not be on each Gadget Server. May use login/password instead of OpenID.

Howard: There have been 3 things we have discussed: (a) authenticate screen in gadget, (b) SAML, (c) OpenID. Looks to me that same issues for SAML and OpenID.

Kris: Problem we had was with subdomains. Simplest use case was Mashup Server and Gadget Server on same domain but widget on a different subdomain

Jon: Should we promote nested IFRAMEs or not for the OpenID/SAML scenario?

Javier: My inclination, as we discussed in separate email, was allowing reconnect helps some but not all cases. We need to have an intermediary hub for all scenarios. But, Kris, you were saying that separate subdomains has issues with single sign-on?

Kris: Partial solution in WebSphere with cookies using the domain name, such as ibm.com, shared between subdomains. Not sure that would work with Tomcat, though

Howard: Are you using servlet filters?

Kris: No, not doing anything in particular

Rama: Another variant is certificate based. Login to single signon. Install certificate, then can use anything that uses the certificate

Kris: We did something via a proxy. Deals with same domain issue. All done at the mashup application level.

Jon: Maybe we need to have a convention for a URL parameter for the security token?

Kris: Yes

Jon: Probably different URL parameters for OpenID vs SAML

Howard: That would satisfy one of the two options, the URL option. We could just flag the other option for later.

Jon: All of this is extra credit for Hub 1.1

Howard: Would really be helpful to figure out nested IFRAMEs questions early

Jon: I've concluded that nested IFRAMEs will be necessary for general support for OpenID and SAML due to the need to have a full page redirect that they require

Howard: We don't have to make the decision. People can choose whatever they need. No matter, we still need to allow reconnect.

Jon/Rama/Howard: Yes, need to add reconnect

Jon: So, consensus is:

  • Widget has responsibility for single sign-on, not the Hub
  • Add reconnect (as we decided last week)

Howard: I'll send my proposals to this list, interop@openajax.org

Howard: To summarize the email threads:

  • Timeout approach doesn't fully address frame phishing
  • So, we decided to hide the iframe when not connected. Presents phishing completely.
  • Timeout logic in the Hub is an optional app-level feature
  • Security tokens are enough for security reasons
  • Add reconnect
  • We discovered that using a nested ManagedHub within the intermediary was losing unsubscribe notices

Jon: Anyone have questions or comments on what Howard said?

Kris: Is intermediary on server?

Howard: Doesn't matter. Several ways to do it, such as a proxy Managed Hub.

Jon: Javier's examples don't use any server technology. Right now the extension is .php, but he was just about to rename the files to .html.

Kris: Does it deal with cross-domain features?

Howard: Intermediary is in same domain as gadgets. But cross-domain?

Jon: Nested Iframe approach can be used to address the cross-domain issues within the widget package, which includes the intermediary, any redirects to authentication servers, and the actual widget

Kris: I'll look at the samples to see if it deals with my use cases

Howard: There are other approaches that don't involve an intermediary Hub, such as a proxy hub approach. Still requires an IFRAME, but is simpler.

Javier: You proposed a separate HubClient class. My thinking is don't put this into the Hub, but show it as an example.

Howard: If multiple people want to intercept, could be contention. Don't want to battle over who is on top.

Javier: I just want to keep the Hub as simple as possible.

Howard: Yeah, could create standard code that shows how to proxy

onUnsubscribe

Howard: If we do it, should be at the same level as onSubscribe and onPublish. Note that a proxy system that uses this can get leaks. This is because onComplete is synchronous. The intermediary has to respond immediately before it talks to the higher level. Note that onSubscribe and onPublish were designed for policy enforcement, not motivated by notification reasons or ability to interpose gateway services, such as to a Comet implementation. One problem with the intermediary Hub is propagation of errors.

Javier: Yes, that's the big problem.

Jon: My thinking was that onUnsubscribe was there for completeness so that the ManagedHub could be notified for all events that come from clients. I wasn't motivated by attempting to allow for proxy hubs.

Howard: OK, we can add this. Just need to be clear that onSubscribe and onPublish are also for notification.

Javier: Optional parameter?

RESOLUTION: Add onUnsubscribe as an optional param to Managed Hub constructor

Best practice to steer clear of fragment identifier

Howard: Yes

Javier: Also, URL parameters should be nice. Add onto parameters that exist already. Don't mess with ones that start with "oah".

Jon: Need a couple of best practices for widgets

Howard: Yes, we do.

RESOLUTION: Best practices needed for fragment identifiers and URL parameters

(Javier and Howard talked about the complexities with SMash and fragment identifiers)

Retrieved from "http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-03-02"
Personal tools