You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Bernhard Hoisl <be...@wu.ac.at> on 2010/01/13 15:54:10 UTC
Wookie with OpenID support?
Just a quick question if it is planned to integrate any sort of OpenID
support in Wookie? Maybe with a call to the REST API before
instantiating a widget? This would simulate a single-sign-on mechanism
on a page where different Wookie widgets are displayed each needing
authentication.
I would need anything like that...
-Bernhard
Re: Wookie with OpenID support?
Posted by Scott Wilson <sc...@gmail.com>.
On 16 Jan 2010, at 12:04, Hugh Barnard wrote:
> Hi Bryan
>
> Thanks very much for this...yes, fits in with what I currently
> understand.
>
> Another area that I need to look at and haven't been into is the key
> arrangements/options for OAuth. It looks like there are symmetric
> and public
> key asymmetric (RSA) options.
>
> I don't personally want 'any' symmetric at the back end because
> this will
> tie me to key distribution of some kind to deal with some of the
> process,
> but I'm not sure whether that's on the table.
There is also a variant called oAuth WRAP that takes place over HTTPS,
and doesn't require any additional encryption at the message level.
> However, I'm not well enough into OAuth to be completely clear about
> any of
> this...
>
> Best regards Hugh
>
>
>
> On Fri, Jan 15, 2010 at 5:06 PM, Copeland, Bryan <
> Bryan.Copeland@nrc-cnrc.gc.ca> wrote:
>
>> Hi Hugh,
>>
>> I think the most important point is they are definitely suited for
>> different parts of the login/secure access process. To simplify, we
>> could
>> call it:
>> 1. Authentication
>> 2. Authorization
>>
>> When it comes to initial login AUTHENTICATION (at least in terms of
>> grasping at the fleeting promise of true SSO) OpenID probably works
>> best. I
>> definitely support keeping OpenID integrations simple, as in: "I'd
>> rather
>> use my passport to get into the countries I visit, not go through the
>> process of signing up for each country as a temp. resident, unless
>> of course
>> I want to spend A LOT of time there because I like the people...)".
>> OpenID
>> should do minimal Authorization (just on access of info attached to
>> your
>> actual OpenID provider) and focus on AUTHENTICATION.
>>
>> While OAuth (with the current 1.0 core + OAuth WRAP extension, or,
>> when the
>> new v2.0 comes out later this yr) works best for AUTHORIZATION of
>> access to
>> third party applications and resources (i.e. once logged in, use an
>> OAuth
>> request to grant Read access for 24 hrs to User 1's "Latest
>> Tweets", from
>> inside a Wookie Twitter widget instance with a specific API key).
>>
>> Actually, FriendFeed has already done the dual integration quite
>> well,
>> although in more of an "Activity Stream" content portal sort of
>> way. Details
>> here:
>> http://bret.appspot.com/entry/oauth-wrap
>> Wookie would go one step further and bring widgetized app
>> functionality
>> into the container.
>>
>> Agreed that the two can easily be confused and used
>> interchangeably/inefficiently, at the same time, I realize they may
>> have
>> other uses outside of this simplified view too.
>>
>> Bryan
>>
>>
>> -----Original Message-----
>> From: Hugh Barnard [mailto:hugh.barnard@googlemail.com]
>> Sent: January 15, 2010 12:47 AM
>> To: wookie-dev@incubator.apache.org
>> Subject: Re: Wookie with OpenID support?
>>
>> On Thu, Jan 14, 2010 at 6:45 PM, Scott Wilson <
>> scott.bradley.wilson@gmail.com> wrote:
>>
>>>
>>> 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!
>>>>
>>>
>> This is a summary, (summarised by another!) of my current
>> understanding:
>>
>>
>>>
>>>
>> http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing
>>>
>>
>> Oauth has appeal for some of my work because it involves 'gateways'.
>>
>> Best regards Hugh
>>
>>
>> --
>> http://www.hughbarnard.org
>> http://www.big-wave-heuristics.com/
>>
>> http://www.hackney-environment-network.org.uk/
>>
>
>
>
> --
> http://www.hughbarnard.org
> http://www.big-wave-heuristics.com/
>
> http://www.hackney-environment-network.org.uk/
Re: Wookie with OpenID support?
Posted by Hugh Barnard <hu...@googlemail.com>.
Hi Bryan
Thanks very much for this...yes, fits in with what I currently understand.
Another area that I need to look at and haven't been into is the key
arrangements/options for OAuth. It looks like there are symmetric and public
key asymmetric (RSA) options.
I don't personally want 'any' symmetric at the back end because this will
tie me to key distribution of some kind to deal with some of the process,
but I'm not sure whether that's on the table.
However, I'm not well enough into OAuth to be completely clear about any of
this...
Best regards Hugh
On Fri, Jan 15, 2010 at 5:06 PM, Copeland, Bryan <
Bryan.Copeland@nrc-cnrc.gc.ca> wrote:
> Hi Hugh,
>
> I think the most important point is they are definitely suited for
> different parts of the login/secure access process. To simplify, we could
> call it:
> 1. Authentication
> 2. Authorization
>
> When it comes to initial login AUTHENTICATION (at least in terms of
> grasping at the fleeting promise of true SSO) OpenID probably works best. I
> definitely support keeping OpenID integrations simple, as in: "I'd rather
> use my passport to get into the countries I visit, not go through the
> process of signing up for each country as a temp. resident, unless of course
> I want to spend A LOT of time there because I like the people...)". OpenID
> should do minimal Authorization (just on access of info attached to your
> actual OpenID provider) and focus on AUTHENTICATION.
>
> While OAuth (with the current 1.0 core + OAuth WRAP extension, or, when the
> new v2.0 comes out later this yr) works best for AUTHORIZATION of access to
> third party applications and resources (i.e. once logged in, use an OAuth
> request to grant Read access for 24 hrs to User 1's "Latest Tweets", from
> inside a Wookie Twitter widget instance with a specific API key).
>
> Actually, FriendFeed has already done the dual integration quite well,
> although in more of an "Activity Stream" content portal sort of way. Details
> here:
> http://bret.appspot.com/entry/oauth-wrap
> Wookie would go one step further and bring widgetized app functionality
> into the container.
>
> Agreed that the two can easily be confused and used
> interchangeably/inefficiently, at the same time, I realize they may have
> other uses outside of this simplified view too.
>
> Bryan
>
>
> -----Original Message-----
> From: Hugh Barnard [mailto:hugh.barnard@googlemail.com]
> Sent: January 15, 2010 12:47 AM
> To: wookie-dev@incubator.apache.org
> Subject: Re: Wookie with OpenID support?
>
> On Thu, Jan 14, 2010 at 6:45 PM, Scott Wilson <
> scott.bradley.wilson@gmail.com> wrote:
>
> >
> > 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!
> >>
> >
> This is a summary, (summarised by another!) of my current understanding:
>
>
> >
> >
> http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing
> >
>
> Oauth has appeal for some of my work because it involves 'gateways'.
>
> Best regards Hugh
>
>
> --
> http://www.hughbarnard.org
> http://www.big-wave-heuristics.com/
>
> http://www.hackney-environment-network.org.uk/
>
--
http://www.hughbarnard.org
http://www.big-wave-heuristics.com/
http://www.hackney-environment-network.org.uk/
RE: Wookie with OpenID support?
Posted by "Copeland, Bryan" <Br...@nrc-cnrc.gc.ca>.
Hi Hugh,
I think the most important point is they are definitely suited for different parts of the login/secure access process. To simplify, we could call it:
1. Authentication
2. Authorization
When it comes to initial login AUTHENTICATION (at least in terms of grasping at the fleeting promise of true SSO) OpenID probably works best. I definitely support keeping OpenID integrations simple, as in: "I'd rather use my passport to get into the countries I visit, not go through the process of signing up for each country as a temp. resident, unless of course I want to spend A LOT of time there because I like the people...)". OpenID should do minimal Authorization (just on access of info attached to your actual OpenID provider) and focus on AUTHENTICATION.
While OAuth (with the current 1.0 core + OAuth WRAP extension, or, when the new v2.0 comes out later this yr) works best for AUTHORIZATION of access to third party applications and resources (i.e. once logged in, use an OAuth request to grant Read access for 24 hrs to User 1's "Latest Tweets", from inside a Wookie Twitter widget instance with a specific API key).
Actually, FriendFeed has already done the dual integration quite well, although in more of an "Activity Stream" content portal sort of way. Details here:
http://bret.appspot.com/entry/oauth-wrap
Wookie would go one step further and bring widgetized app functionality into the container.
Agreed that the two can easily be confused and used interchangeably/inefficiently, at the same time, I realize they may have other uses outside of this simplified view too.
Bryan
-----Original Message-----
From: Hugh Barnard [mailto:hugh.barnard@googlemail.com]
Sent: January 15, 2010 12:47 AM
To: wookie-dev@incubator.apache.org
Subject: Re: Wookie with OpenID support?
On Thu, Jan 14, 2010 at 6:45 PM, Scott Wilson <
scott.bradley.wilson@gmail.com> wrote:
>
> 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!
>>
>
This is a summary, (summarised by another!) of my current understanding:
>
> http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing
>
Oauth has appeal for some of my work because it involves 'gateways'.
Best regards Hugh
--
http://www.hughbarnard.org
http://www.big-wave-heuristics.com/
http://www.hackney-environment-network.org.uk/
Re: Wookie with OpenID support?
Posted by Hugh Barnard <hu...@googlemail.com>.
On Thu, Jan 14, 2010 at 6:45 PM, Scott Wilson <
scott.bradley.wilson@gmail.com> wrote:
>
> 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!
>>
>
This is a summary, (summarised by another!) of my current understanding:
>
> http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing
>
Oauth has appeal for some of my work because it involves 'gateways'.
Best regards Hugh
--
http://www.hughbarnard.org
http://www.big-wave-heuristics.com/
http://www.hackney-environment-network.org.uk/
Re: Wookie with OpenID support?
Posted by Scott Wilson <sc...@gmail.com>.
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 Widget
OK, 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 of
>>> how we would want to proceed.
>> +1 - thanks Bryan
>> I'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
Re: Wookie with OpenID support?
Posted by Bernhard Hoisl <be...@wu.ac.at>.
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.
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.
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.
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 of
>> how we would want to proceed.
>
> +1 - thanks Bryan
>
> I'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
>
Re: Wookie with OpenID support?
Posted by Ross Gardler <rg...@apache.org>.
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 of
> how we would want to proceed.
+1 - thanks Bryan
I'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
Re: Wookie with OpenID support?
Posted by Scott Wilson <sc...@gmail.com>.
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 of
how we would want to proceed. I'll try and work up an "oAuth only"
flow too using the same format.
S
> Bryan
>
>
> -----Original Message-----
> From: Hugh Barnard [mailto:hugh.barnard@googlemail.com]
> Sent: January 13, 2010 11:35 AM
> To: wookie-dev@incubator.apache.org
> Subject: Re: Wookie with OpenID support?
>
> Yes, I'd prefer Oauth too...It seems to me to fit better because it's
> service oriented...
>
> On Wed, Jan 13, 2010 at 3:17 PM, Scott Wilson <
> scott.bradley.wilson@gmail.com> wrote:
>
>> On 13 Jan 2010, at 14:54, Bernhard Hoisl wrote:
>>
>> Just a quick question if it is planned to integrate any sort of
>> OpenID
>>> support in Wookie? Maybe with a call to the REST API before
>>> instantiating a
>>> widget? This would simulate a single-sign-on mechanism on a page
>>> where
>>> different Wookie widgets are displayed each needing authentication.
>>>
>>> I would need anything like that...
>>>
>>> -Bernhard
>>>
>>
>> Hi Bernhard,
>>
>> I hadn't thought of integrating OpenID in Wookie, however I would
>> very much
>> like to have oAuth support in Wookie so that a Widget requiring
>> access to a
>> remote service could request oAuth authorization by the user to the
>> remote
>> service via Wookie in a similar manner to how Shindig supports this
>> capability.
>>
>> For authentication, Wookie assumes that applications authenticate
>> users, as
>> this is how we assume concerns are separated - a single Wookie
>> server can
>> support multiple applications, potentially in different
>> organisations, and
>> so we do not implement authentication concerns.
>>
>> Maybe some use-cases could help articulate how an OpenID feature
>> might
>> work?
>>
>> S
>>
>>
>
>
> --
> http://www.hughbarnard.org
> http://www.big-wave-heuristics.com/
>
> http://www.hackney-environment-network.org.uk/
RE: Wookie with OpenID support?
Posted by "Copeland, Bryan" <Br...@nrc-cnrc.gc.ca>.
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...
Bryan
-----Original Message-----
From: Hugh Barnard [mailto:hugh.barnard@googlemail.com]
Sent: January 13, 2010 11:35 AM
To: wookie-dev@incubator.apache.org
Subject: Re: Wookie with OpenID support?
Yes, I'd prefer Oauth too...It seems to me to fit better because it's
service oriented...
On Wed, Jan 13, 2010 at 3:17 PM, Scott Wilson <
scott.bradley.wilson@gmail.com> wrote:
> On 13 Jan 2010, at 14:54, Bernhard Hoisl wrote:
>
> Just a quick question if it is planned to integrate any sort of OpenID
>> support in Wookie? Maybe with a call to the REST API before instantiating a
>> widget? This would simulate a single-sign-on mechanism on a page where
>> different Wookie widgets are displayed each needing authentication.
>>
>> I would need anything like that...
>>
>> -Bernhard
>>
>
> Hi Bernhard,
>
> I hadn't thought of integrating OpenID in Wookie, however I would very much
> like to have oAuth support in Wookie so that a Widget requiring access to a
> remote service could request oAuth authorization by the user to the remote
> service via Wookie in a similar manner to how Shindig supports this
> capability.
>
> For authentication, Wookie assumes that applications authenticate users, as
> this is how we assume concerns are separated - a single Wookie server can
> support multiple applications, potentially in different organisations, and
> so we do not implement authentication concerns.
>
> Maybe some use-cases could help articulate how an OpenID feature might
> work?
>
> S
>
>
--
http://www.hughbarnard.org
http://www.big-wave-heuristics.com/
http://www.hackney-environment-network.org.uk/
Re: Wookie with OpenID support?
Posted by Hugh Barnard <hu...@googlemail.com>.
Yes, I'd prefer Oauth too...It seems to me to fit better because it's
service oriented...
On Wed, Jan 13, 2010 at 3:17 PM, Scott Wilson <
scott.bradley.wilson@gmail.com> wrote:
> On 13 Jan 2010, at 14:54, Bernhard Hoisl wrote:
>
> Just a quick question if it is planned to integrate any sort of OpenID
>> support in Wookie? Maybe with a call to the REST API before instantiating a
>> widget? This would simulate a single-sign-on mechanism on a page where
>> different Wookie widgets are displayed each needing authentication.
>>
>> I would need anything like that...
>>
>> -Bernhard
>>
>
> Hi Bernhard,
>
> I hadn't thought of integrating OpenID in Wookie, however I would very much
> like to have oAuth support in Wookie so that a Widget requiring access to a
> remote service could request oAuth authorization by the user to the remote
> service via Wookie in a similar manner to how Shindig supports this
> capability.
>
> For authentication, Wookie assumes that applications authenticate users, as
> this is how we assume concerns are separated - a single Wookie server can
> support multiple applications, potentially in different organisations, and
> so we do not implement authentication concerns.
>
> Maybe some use-cases could help articulate how an OpenID feature might
> work?
>
> S
>
>
--
http://www.hughbarnard.org
http://www.big-wave-heuristics.com/
http://www.hackney-environment-network.org.uk/
Re: Wookie with OpenID support?
Posted by Scott Wilson <sc...@gmail.com>.
On 13 Jan 2010, at 14:54, Bernhard Hoisl wrote:
> Just a quick question if it is planned to integrate any sort of
> OpenID support in Wookie? Maybe with a call to the REST API before
> instantiating a widget? This would simulate a single-sign-on
> mechanism on a page where different Wookie widgets are displayed
> each needing authentication.
>
> I would need anything like that...
>
> -Bernhard
Hi Bernhard,
I hadn't thought of integrating OpenID in Wookie, however I would very
much like to have oAuth support in Wookie so that a Widget requiring
access to a remote service could request oAuth authorization by the
user to the remote service via Wookie in a similar manner to how
Shindig supports this capability.
For authentication, Wookie assumes that applications authenticate
users, as this is how we assume concerns are separated - a single
Wookie server can support multiple applications, potentially in
different organisations, and so we do not implement authentication
concerns.
Maybe some use-cases could help articulate how an OpenID feature might
work?
S