Security Minutes 2009-03-06
From MemberWiki
URL: http://www.openajax.org/member/wiki/Security_Minutes_2009-03-06
Attendees
- Jon Ferraiolo, IBM
- Krishna Shankar, Cisco
- Javier Pedemonte, IBM
- Suresh Chari, IBM
- Howard Weingram, TIBCO
- Larry Koved, IBM
Minutes
(Continued discussion on Mashup Authentication and Authorization)
Krishna: Are we looking at OpenSocial technologies? OAuth?
Suresh: Nothing yet on authoriziation, just authentication so far. First making sure that authentication issues do not warrant changes to Hub 1.1
Jon: Looks to me that OAuth uses similar redirect techniques as OpenID. Most likely, what we figure out for OpenID and SAML will work with OAuth. So far, it looks like we have what we need in Hub 1.1 and these other technologies, but we might need standardization of URL params and some other things to get interoperability
Krishna: OAuth also has scopes that we need to deal with
Suresh: Last time we met we talked about what we need to do for authentication of gadgets and what we have to do to Hub 1.1. We came up with 3 options, which I am renumbering from our last phone call. New numbers:
- Option 1: Don't do anything. Just hope it fits in with our current timeout approach. But of limited value because login/password dialogs will usually exceed the timeout
- Option 2: Load an authentication gadget which connects immediately to the Hub. The gadget authenticates with login/password, OpenID or whatever. After authenticating, it loads the real gadget via a nested IFRAME who size is 100%/100%. Includes a proxy for Hub messages. Javier has a sample for this
- Option 3: Load an authentication gadget, then login/password, then disconnect and load real gadget, which reconnects
Howard: These approaches are pretty straightforward for use cases we are discussing. Timeout wouldn't be a problem. Phishing can be addressed with hiding and a token. For reconnect, does one isolate the real widget via a nested IFRAME or tell container to change the URL to the real gadget? For reconnect, container should accept base URLs from a particular domain. For the reconnect scenario, the authorization server has to know something about OpenAjax.
Suresh: Yes
Howard: Got to make the login screen a HubClient to prevent frame phishing
Suresh: Simple scenario is where gadget has userid/password then redirects to real gadget. Get a hub connection, get userid/password, then does #2 or #3.
Jon: What if the authentication server is a 3rd party service like Google or Verisign OpenID? Will that 3rd party service need to know about OpenAjax technologies?
Suresh: Doesn't need to know about the Hub, but if you show login/password dialog in a nested iframe, that isn't a secure practice
Howard: Unless protected against frame phishing
Suresh: Load gadget from gadgetserver.com and used OpenID from Google. Authentication gadget connects to Hub. Now has to do authentication. Today, no awareness on authentication server. After authentication, authentication server redirects to gadget server.
Howard: If user is already logged into the mashup, then authentication server doesn't have to bring up a UI.
Suresh: I don't think hiding is good to stop frame phishing. Just because hidden, still JavaScript can run and do malicious things.
Howard: That attack is already possible without frame phishing
Suresh: The security token allows the mashup server to be sure that the gadget is what it tried to load
Howard: What I'm saying is that to do any of this requires malicious code, which allows lots of things. Problem with timeouts. Difficult when you have slow servers and difficult for troubleshooting. Timeouts generate false positives. Causes user to lose confidence in the system. Will dull user to dangers of frame phishing. It is possible to keep the timeouts, but will make the system look less robust
Jon: I see it similar to browser timeout strategy when loading a web page
Howard: Need a solution that is both secure and has proper human factors.
Jon: If there is a timeout, the mashup should tell use and ask whether to try again
Howard: Mashup app often will have its own timeouts. Do we want redundant timeouts?
Jon: Suresh and I are saying yes on hidden, yes on token, yes on timeouts. 30 seconds too long.
Javier: I'm torn. I understand what Howards is saying, but since we are already going to the effort of loading the gadgets, might as well handle timeout logic
Howard: Application decision, not a Hub decision
Jon: How about a parameter, such that you can easily turn off the timeouts?
Howard: If we put it in, default to draconian timeouts by default, allow app to make timeout less draconian, and put explanations in the spec
Jon: My instincts are to put timeouts in the Hub as a convenience to mashup app developers
Howard: Timeouts are a gadget app management feature. Would have to deal with timeouts at that level anyway
Javier: I think it's worthwhile to keep timeouts and make them overridable
Howard: Must be overridable
Suresh: I agree
Howard: What are the defaults?
Suresh/Javier: 10-15 seconds
Suresh: Worry is that user might type user/password during that period
Howard: Biggest attack opportunity is at the beginning
Suresh: The security message has proven to be startling to users
Howrad: First time, yes, but what about the 50th time? People become numb. Avoid false positives.
Suresh: Conclusion: There are issues with timeouts. Most feel there is value in timeouts. Agreement: authentication gadget, disconnects, reconnects to real gadget
Howard: I'm OK as long as Hub supports #2 and #3. OK if our examples show #2 (isolation approach) as long as #3 (communication approach) is supported by the Hub.
(Then we had discussion about #2 as "intermediary nested iframe, which might be done via a hub proxy or a nested managed hub. To make nested managed hub approach robust, would need to get around the synchronous nature of onComplete because the nested iframe would return onComplete immediately which would happen before the onComplete for the intermediary completed. Delegates to parent except for unload.)
Suresh: Need to look at the overhead of nested iframe
Howard: Any problems with reconnect that is now in the code?
Javier: Not usre, but probably will work for postMessage but not for smash.
Howard: Right
Jon: For reconnect, how is the URL changed?
Howard: Redirect just happens. Manager app can have a list of origins. When connect is called again, Manager App can verify that the URL is on the list. Same tokens used as before.
Jon: Yes
Jon: In March, we need to focus on finishing Hub 1.1, and then work on updated authentication examples in April
Howard/Javier: Only code change for now is getting reconnect to work
Howard: OK to work on the examples later
RESOLUTIONS:
- Timeouts stay in.
- Reconnect discussions go into Interop group.
- Reconnect needs to work with FIM.
- Next Security TF meeting in April once updated examples are ready.
