couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Caprari <matteo.capr...@gmail.com>
Subject Re: draft openid implementation
Date Tue, 12 Jan 2010 22:06:07 GMT
You're right. Simple and works, too.

To recap:
- a roundtrip to the endpoint verifies user claim of <openid>
- the user with id org.couchdb.user:<openid> is loaded or created and loaded
- a cookie is installed using couch_httpd_auth:cookie_auth_header

from now on _session returns the right stuff.

Some stuff is not quite right yet:
- salt is not random
- it only sopports openid 1.1
- it has only been tested against my blog and myopenid.com

eopeind author suggested another library that may support openid 2,
I'll try to add it after a code cleanup and some tests.

To test, hit
http://caprazzi.net:5984/_session?openid=auth-request&openid-identifier=<your_openid_identifier>

You should be redirected to your your provider and then back to
caprazzi.net. After that go to _utils and see how futon likes it.

cheers

On Tue, Jan 12, 2010 at 4:52 PM, Chris Anderson <jchris@apache.org> wrote:
> On Tue, Jan 12, 2010 at 2:01 AM, Matteo Caprari
> <matteo.caprari@gmail.com> wrote:
>> An openid signup should create a real user in the system, so apps need
>> not to know about openid. As for roles I think by defult no roles
>> should be added, but I may be wromg here.
>>
>> The implementation is so short of functionalities that everything is
>> up for debate, but in short this is my plan:
>>
>> - user, couch and endpoint interact so that the couch verifies that
>> the user owns the id
>> - couch tries to find a user mapped the userid
>> - if a user is found, a cookie compatible with couch_httpd_auth is installed
>>
>> - if a user is not found, this is a signup process: a new user
>> document is stored and a cookie is given to the client. The user can
>> then optionally be prompted to change his username.
>>
>> As a user may be mapped to multiple openids, I think the user document
>> could contain a an array of verified openids for that user.
>>
>> {
>> _id: 'org.couchdb.user:<openid>',
>> username: <openid>,
>> openid: [<openid>],
>> roles: []
>> }
>>
>> - openid-to-user mappings could also be stored in separate documents,
>> especially if we don't want to bloat the user document with all future
>> authentication schemes.
>> - I haven't figured out exactly how to generate a cookie that works
>> with the standard auth.
>
> This sounds reasonable to me. The cookie-making code should be in
> there, I think it is pretty simple.
>
>>
>> -teo
>>
>> On Tue, Jan 12, 2010 at 9:28 AM, Brian Candler <B.Candler@pobox.com> wrote:
>>> On Mon, Jan 11, 2010 at 02:34:23PM +0000, Matteo Caprari wrote:
>>>> - It uses its own cookie scheme to maintain authentication. Ideally it
>>>> should install
>>>> a cookie compatible with couch_httpd_auth, but that requires mapping
>>>> an openid to a real user or
>>>> creating a real user.
>>>
>>> How do openid users get assigned to roles, or is that not done?
>>>
>>> Does that mean that your application's validate_doc_update currently has to
>>> have hard-coded the capabilities for individual openids?
>>>
>>> Thanks,
>>>
>>> Brian.
>>>
>>
>>
>>
>> --
>> :Matteo Caprari
>> matteo.caprari@gmail.com
>>
>
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>



-- 
:Matteo Caprari
matteo.caprari@gmail.com

Mime
View raw message