Security Minutes 2009-02-11

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/Security_Minutes_2009-02-11

Contents

Attendees

  • Bertrand Le Roy - MS
  • Krishna Shankar - Cisco
  • Kin Blas- Adobe
  • Uramoto - IBM
  • Adam Greenberg - Fidelity Investments
  • Javier Pedemonte - IBM
  • David Boloker - IBM
  • Jon Ferraiolo - IBM
  • Howard Weingram - Tibco
  • Suresh Chari - IBM
  • Larry Koved - IBM

Minutes

Intro

Larry: What's the next step for Security TF now that Hub 1.1 is far along? Perhaps look into how do you authenticate with backend services and what should a component be allowed to do on behalf of the user. What are the important issues? What use cases? Is there something else more pressing for us to look at?

Issues

Suresh: The wiki page we created shows some issues based on our experience. Looking for feedback and prioritization and decisions about what we should do. Let's open the floor.

Howard: Quick recap?

  • Single sign-on - TBD
  • Authentication - uid/pw, SAML, OpenID
  • Authorization - OAuth, ???

Suresh: Have had a number of people ask to allow single sign-on for multiple gadgets. One use case around using SAML. Basically, mashup server allows user to login and generates a SAML token. Another scenario around OpenID. Mashup server acts as an OpenID server. These are the scenarios we have senen.

Larry: If you are using a gadget and need to authenticate to a service, 3 ways we are seeing:

  1. usserid/password
  2. SAML
  3. OpenID

Larry: Separate from federation question.

Krishna: Looking at OAuth?

Larry/Suresh: Yes, definitely.

Krishna: What are we going to do, doc or code?

Larry: A number of options. Whitepaper, Interop event, core reference implementation. For some technologies, there already is a reference implementation, such as OpenID or OAuth. I'm inclined to push towards interop testing once we agree on some sort of standard

Howard: SOme things we could do

  1. Use cases
  2. Best practices doc
  3. "Standards" -- may not need to define new standards
  4. Reference implementation of these standards (if needed)

Jon: Might do reference implementation where we integrate other standards into OpenAjax's existing technologies

Adam: (Comments on the web page)

  • Auth @ gadget server -- not federated.
  • Others, federated -- prior coordination.
  • Independent vs. federated model
  • Auth before or after the gadget has been downloaded.
  • Without prior authorization, there can be arbitrary mashups.

Suresh: We have been talking about authentication before loading could interfere with Hub timeout logic.

Larry/Suresh: However, this would interfere with frame phishing w/ the hub. Need to figure out how to do this in the context of the hub. Maybe a white paper.

Howard: I do have a possible solution. Will send it offline.

Larry: For authorization, we have OAuth. Any others that people are seeing in practice?

(silence)

Howard: I would say that authentication is the bigger requirement. Authorization is often more application-specific.

Larry: Authentication is easier to standardize. Authorization will be harder?

Howard: Mashup developers tend to be lightweight. Has to be simple for adoption.

Larry: Totally agree.

Suresh: One piece to look at is OpenSocial.

Jon: OpenSocial is fully on board OpenID and OAuth.

Larry: I haven't heard any new requirements. Just that it is hard to do standards around authorization. Also, federated or not, and whether to do pre-authorization or post-authorization. What are the next steps?

Resolution: In the wiki:

  • Start with use cases.
  • Then classify the problems.
  • List the technologies.
  • Break out scenarios into separate pages, with a cover page.
  • What about metadata about authentication / authorization systems are required.
  • What are the implications of session timeouts / logouts?
  • What are the limitations of federation (e.g., OpenID, SAML)?

(discussion about federated vs non-federated)

(2009.02.12 Howard adds: in the discussion, "federated" involved dependencies between mash-up server and gadget servers that would require some degree of collaboration between the mash-up server operator and gadget server operator. Non-federated minimized such dependencies.)

Howard: Lots of things in the long tail are independent. Quicker adoption if fewer requirements.

Jon: I think we need to support both. Enterprises are adopting mashup technologies but want security and single-signon authentication and have adopted SAML in various places

Howard: Maybe we encourage via best practices towards lighterweight approaches. Almost certainly will need to add changes to the OAA Gadgets spec to indicate the type of authentication required. Maybe push people towards an approach where data is what you want to protect

(2009.02.12 Howard adds: focus on protecting the underlying data rather than the gadgets)

Jon: Generally I agree with that

Suresh: Yes, absolutely agree with that

Larry: Clearly people are looking for single signon

Howard/Larry: How about scenarios where widget will only participate in mashup with certain widgets that they are allowed to talk to

Howard: I'm looking at that now

Howard/Suresh: Doesn't fit into same sort of ... that we have been talking about

(2009.02.12 Howard: What I said here is that there is a distinction between this and user authentication. The fact that a user may have permission to view a gadget does not ensure that this gadget can safely be embedded without sandboxing in all page of the application. And if the gadget is sandboxed, it may or may not trust the mash-up enough to publish certain data out of its sandbox.)

Larry/Howard: This is service to server

Larry: Put that as a separate issue

Howard: Gadget knows it wants to publish the foo topic but doesn't want to publish into any mashup. Financial info, for example.

(2009.02.12 Howard : What I was saying at this point in the call was this: gadgets can be embedded in many different mash-ups, not all of which are trustworthy. So a gadget needs to be able to authenticate the manager application and determine whether that application is allowed to publish/subscribe to the specified topic. Only then should the gadget subscribe to or publish on that topic.)

Adam: Another possible requirement. In event of federated authentication scheme, in our experience it is a trust transfer. You can authenticate from the original, then federate to a second. Could be tied between the two, such as logout in one stops the other. But if not, then you have in effect two independent credentials. Concern that any model would lead to need to eradicate existing state or other defensive mechanism.

Howard: User may log out but doesn't eradicate credentials. Also, case where browser is blown away. Yes, as we go through, need to ask what's the weakest link

Adam: Also need to remember OpenID and SAML have different implementationss and different sets of options. Mayb need to look at other safeguards to overlay it

Larry: Need to start putting up use cases. May not be able to address all of them in detail.

Future phone calls

Larry: Continue once a week for a short period. Want to make progress before an OpenSocial event in March. Then maybe every two weeks.

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