Bugzilla – Full Text Bug Listing
| Summary: | [server] Investigate and implement OAuth for communication between Orion services | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Szymon Brandys <Szymon.Brandys> | ||||
| Component: | Server | Assignee: | Simon Kaegi <simon_kaegi> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P2 | CC: | bokowski, mail, simon_kaegi, tomasz.zarna | ||||
| Version: | 0.2 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Szymon Brandys
I've been spending a bit of time looking at how we might use OAuth in the context of the recent work on the File Client. At the moment we're using name/password to establish a jsession and then using the fact that the cookies are passed around to keep the session alive. This was ok when everything was on one site but now as we split the pieces out into plugins where appropriate we need to be really careful with using cookies to prove identity. In particular, our use of IFrames and window.postMessage allows one to workaround the browsers single-origin-policy but does leave us vulnerable to cross-site request forgery (CSRF pronounced see-surf) if not careful. The way to protect against this sort of an attack is to require the user to pass a token not automatically supplied by the browser to prove identity -- OAuth and in particular the work being done in OAuth2 being the front runner for a standardized approach there that does not require the browser to hold a "secret". We need to begin trying out some of the authentication workflows and here's a quick strawman using BEARER authentication to try out the absolute simplest case. 1) A FileService plugin (on https://file.com/plugin.html) is installed and registers a FileService that uses OAuth BEARER authentication. At the moment OAuth does not stipulate a discovery mechanism so I'd suggest using the service properties to help out and state that the service needs BEARER authentication and also to provide an authorization endpoint for the OAuth negotiation. 2) The Orion side of the fileclient (on https://orion.eclipse.org) needs to be OAuth aware and use the service properties from the FileService to create an auth_token that can be used for BEARER authentication. To do this it uses the service properties to manufacture a url as per the OAuth2 "Implicit" workflow and with help from the user opens a window where username and password can be entered. 3) Assuming the user approves the request and authenticates appropriately there will be a redirect dance where eventually an Orion page will retrieve the auth_token from the "fragment" portion of the pages location and then (for now) save it in localStorage and close the window. 4) The orion client(s) can then use the auth_token and pass it to the FileService where it will in turn be sent down as an Authentication header and eventually the relevant resource returned, written, copied, moved, etc. 5) BEARER tokens are typically fairly short-lived so we'll need to figure out if we can use refresh tokens as from a UX perspective I'd hate to have to have the user log-in again inside of the same logical session. -- Some pieces I can think we need to begin working on to try this out. 1) A username/password auth service that can return us an auth_token and follow the OAuth workflow (Apache Amber?) 2) A fileservice that can use auth_token BEARER/MAC based authentication. 3) A fileclient that understands how to do the "implicit" oauth The above description is obviously pretty shallow but hopefully enough to begin putting some flesh on the workflow. How does this work with existing protocols and servers that don't check additional authorization tokens? For example, WebDAV? (In reply to comment #2) > How does this work with existing protocols and servers that don't check > additional authorization tokens? For example, WebDAV? It doesn't directly. So in particular for services that are using BASIC, DIGEST, or session cookies we're going to need to "de-fang"(*) XHR requests and possibly provide some sort of token to the plugin to ensure we're not exposing the plugin's origin server to CSRF type attacks. These are all nasty problems and clearly we do not have all the answers but I think it's critically important that we start going through these workflows to figure out what we can and cannot do here. In particular, I'm trying to explore how far Orion can get without having to resort to using something like a trusted server-side proxy. With that said, using a server-side proxy as part of Orion may be inevitable. (* By de-fang I mean remove authorization material from the http headers that the browser automatically supplies when we create an XHR) Another place where I'm looking for making basic/digest or form-based authentication into something that looks more like OAuth is the work done by "XAuth". This might be a good approach to look at for at the very least the short-term. Created attachment 192377 [details]
OAuth Protocol Sequence Diagram
I had done the study in understanding OAuth protocol. And had created the message sequence diagram for the same. So, just attaching it in case it is useful. The message format or structure is added as comments. So, while studying the sequence diagram, hover the mouse to the comment icon and it will show the message format.
Not for 0.2, but setting to P2 priority and I expect this will be on the plan for next release. Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |