On 14 Jan 2010, at 17:09, Bernhard Hoisl wrote:
Hi all,thanks for your replies. As I'm pretty new to these things I am not 100% sure if I understood the pros and cons of OpenID and OAuth and their implementation costs correctly. But I will try to figure it out for myself in the next days - need some more thinking. Bryan's sequence diagram is really helpful in this!I have thought of an authentication process for several widgets displayed in a learning environment (e.g. Moodle, Elgg etc.). The problem are the web-services which are called by the widgets. I need to somehow grant access to the web-services only to logged-in users.
This is the use-case that oAuth serves - for example, this is how the Twitter API works with third-party apps. See http://oauth.net/ and http://apiwiki.twitter.com/OAuth-FAQ for more details.
I have thought of something like that: A user logs-in to a learning environment (e.g., Moodle, Elgg) which displays several widgets. The log-in is done by using OpenID. The OpenID identifier is then passed to Wookie which stores it in its internal database together with a token (hash). That means Wookie can trust the user because he has successfully authenticated himself using an OpenID provider. Then Elgg requests a widget from Wookie, which is displayed. The user now, for example, clicks on a button which invokes a web-service. The call to the web-service has to include the token. The web- service can retrieve the token and can itself make a call to the Wookie REST API, where we have to implement a new service which just compares the token passed through the web-service with the one previously stored in Wookie's internal database. If the tokens are identical access is granted, otherwise an error message is thrown.
If you look at the oAuth guide this should help - the basic flow of events using oAuth would be something like this:
- User logs into the application (e.g. Elgg) - User adds the "Twitter" Wookie Widget to their profile page - User clicks the "Authorize Me!" button in the widget- Widget calls "authorize()" method of the Wookie oAuth JavaScript API, which launches a Twitter Authorization page in a new window, passing in Wookie's consumer key, token, and redirection URL - User logs into Twitter in the new window, and authorizes the Twitter Wookie Widget to access the Twitter API
- Twitter redirects to Wookie with an authz token - Wookie caches the token in the DB- Wookie sends an "authorized" event to the widget instance in Elgg through the JS API - Widget calls the Wookie oAuth JS API with a "getData" request to the Twitter web API - Wookie oAuth JS API calls Wookie's proxy service, which sends the API request along with the token to Twitter
- Twitter sends the data back to the WidgetOK, that sounds pretty long winded, however this only happens the first time, in future its just:
- User accesses their profile page in Elgg - Widget calls Wookie oAuth JS API with a "getData" request- Wookie oAuth JS API calls Wookie's proxy service, which sends the API request along with the cached token to Twitter
- Twitter sends the data back to the Widget
Or, as every external service has to be proxified anyways the api key could be used for authentication (isthe API key included when proxifying a URL?). That means if a user sees a widget, he has to be logged in (=authenticated anyways). So a web-service just have to check if the api_key is right. Then I would have an application based authentication instead of a user based, but that would be fine with me.
Yes, the API key is always taken into account when the proxy service is invoked, as this is part of how Wookie identifies a widget instance. That could be used to create a shared secret with the web service, but wouldn't really work in the same sort of standards- compliant fashion as oAuth.
I don't know if this is the ideal solution but I another one hasn't crossed my mind yet. Authorization issues are not addressed at all, for example. Any suggestions?
-Bernhard Ross Gardler wrote:On 14/01/2010 09:36, Scott Wilson wrote:On 13 Jan 2010, at 23:36, Copeland, Bryan wrote:Hi, I've done similar OpenID/OAuth integrations before, so a high level overview of how it might work in Wookie could somehow be helpful: http://cwiki.apache.org/confluence/display/WOOKIE/Wookie+OpenID+support I thought it might belong on the wiki where others can add more details about how it might work, and, most importantly, what they'd like to accomplish with it...This is fantastic Bryan - exactly what we need to get a shared idea ofhow we would want to proceed.+1 - thanks BryanI've create an issue to track this, discussion can carry on here as I've linked the thread from the issue:https://issues.apache.org/jira/browse/WOOKIE-100 Ross
smime.p7s
Description: S/MIME cryptographic signature
