You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Dave <sn...@gmail.com> on 2008/06/09 13:55:08 UTC

Roller OpenID requirements and need for new DB fields

Now that Matt has upgraded us to Spring Security, I'm reviewing the
Open ID for Roller proposal again.

    http://cwiki.apache.org/confluence/x/zVAB

The requirements section of the proposal is a little to complicated
and mixes in implementation details. Below are what I believe to be
the core requirements for the project, in priority order.

Open ID for Roller Requirements

1) Allow new users to register and login via OpenID

2) Allow existing users to login via OpenID
i.e. by associating a Roller user account with an Open ID identity

3) Allow those who wish to leave comments to login via OpenID

4)  Allow users to associate multiple OpenID accounts with one Roller account
i.e. associate multiple Open ID identities with one Roller user

Does that sound complete?

Judging from the Spring Security 2.0 docs (http://tinyurl.com/3ne8pb),
supporting #1 should be pretty easy. We'll have to figure out how to
configure Spring Security, possibly adding some extension classes, to
support #2 through #4.

Allen Gillland raised a concern with adding OpenID specific fields to
Roller tables, but we do need some way to store a user's OpenID URI
(or list of URIs) in Roller. Could we do the same thing by adding a
new 'roller_openid' table?

- Dave

Re: Roller OpenID requirements and need for new DB fields

Posted by Ian Kallen <ik...@technorati.com>.
Roller should not only be an OpenID relying party, it should be a server 
too. If you want to leave a comment on a blog that accepts OpenID, your 
blog should be able to vouch for you that you are really the owner of 
the URL associated with comment.

Say I'm leaving a comment on your blog that accepts OpenID for comments. 
Your Roller installation will ask mine (that acts as an OpenID server) 
if I'm logged in and redirect me back to mine where I will be asked to 
allow your server to verify my identity. My server should cache these 
permission selections - I would imagine the Roller OpenID data model 
would be adapted to accommodate this.

So I think there are two model additions:
*) associate a Roller user profile with external OpenID URLs that vouch 
for them. Yes, #4 below implies a plurality, though asking users to just 
pick one may be a fine place to start.
*) track a Roller user's selections of OpenID relying parties that are 
permitted to verify his/her ownership of the Roller blog URL

Also, perhaps this is an enhancement to requirement #3 below: Enable 
blog owner to configure their roller blog comment handling policy with 
regards to OpenID. The use case is that if you know that the commenter 
is authentic (i.e. their blog is an OpenID server), you may wish to 
bypass moderation.

Sorry if this sounds convoluted... OpenID is seemingly always a lot 
harder to explain and specify than to use and implement.
-Ian

Dave had written and probably intended:
> Now that Matt has upgraded us to Spring Security, I'm reviewing the
> Open ID for Roller proposal again.
>
>     http://cwiki.apache.org/confluence/x/zVAB
>
> The requirements section of the proposal is a little to complicated
> and mixes in implementation details. Below are what I believe to be
> the core requirements for the project, in priority order.
>
> Open ID for Roller Requirements
>
> 1) Allow new users to register and login via OpenID
>
> 2) Allow existing users to login via OpenID
> i.e. by associating a Roller user account with an Open ID identity
>
> 3) Allow those who wish to leave comments to login via OpenID
>
> 4)  Allow users to associate multiple OpenID accounts with one Roller account
> i.e. associate multiple Open ID identities with one Roller user
>
> Does that sound complete?
>
> Judging from the Spring Security 2.0 docs (http://tinyurl.com/3ne8pb),
> supporting #1 should be pretty easy. We'll have to figure out how to
> configure Spring Security, possibly adding some extension classes, to
> support #2 through #4.
>
> Allen Gillland raised a concern with adding OpenID specific fields to
> Roller tables, but we do need some way to store a user's OpenID URI
> (or list of URIs) in Roller. Could we do the same thing by adding a
> new 'roller_openid' table?
>
> - Dave
>   


-- 
Ian Kallen || Architect, Technorati Inc. || m: 415.505.5208
blog@ http://www.arachna.com/roller/page/spidaman


Re: Roller OpenID requirements and need for new DB fields

Posted by Allen Gilliland <Al...@Sun.COM>.

Dave wrote:
> Now that Matt has upgraded us to Spring Security, I'm reviewing the
> Open ID for Roller proposal again.
> 
>     http://cwiki.apache.org/confluence/x/zVAB
> 
> The requirements section of the proposal is a little to complicated
> and mixes in implementation details. Below are what I believe to be
> the core requirements for the project, in priority order.
> 
> Open ID for Roller Requirements
> 
> 1) Allow new users to register and login via OpenID
> 
> 2) Allow existing users to login via OpenID
> i.e. by associating a Roller user account with an Open ID identity
> 
> 3) Allow those who wish to leave comments to login via OpenID
> 
> 4)  Allow users to associate multiple OpenID accounts with one Roller account
> i.e. associate multiple Open ID identities with one Roller user
> 
> Does that sound complete?

#1-3 seem logical enough.

#4 still eludes me.  I don't see why someone would need to specify more 
than one system that they plan to authenticate against.  You only have 
to login once to get into the system, so how would the other OpenIDs be 
used?


> 
> Judging from the Spring Security 2.0 docs (http://tinyurl.com/3ne8pb),
> supporting #1 should be pretty easy. We'll have to figure out how to
> configure Spring Security, possibly adding some extension classes, to
> support #2 through #4.

I think you'll need extension classes for all of #1-4.  You'll need some 
special code that can take an OpenID and verify it against its provider 
so that the user gets a Session in Acegi.

The exact flow of events that take place in an OpenID login would be 
nice to see on the proposal since it's not clear in my mind right now.


> 
> Allen Gillland raised a concern with adding OpenID specific fields to
> Roller tables, but we do need some way to store a user's OpenID URI
> (or list of URIs) in Roller. Could we do the same thing by adding a
> new 'roller_openid' table?

I am still against any openid specific tables or columns.  I think we 
can provide a more generic solution that solves for OpenID and other 
potential use cases down the road.

Why not a roller_userattr table?

create table roller_userattr(
   user_id varchar(48) not null,
   name varchar(64) not null,
   value varchar(255)
);

Then you can associate any extra information needed about any user, 
including OpenIDs.  You can use these queries to get either the OpenIDs 
for a user or the user for a given OpenID ...

select value from roller_userattr where user_id = 'userId' and name = 
'openid.urls';

select * from rolleruser ru,roller_userattr rua where ru.id = 
rua.user_id and rua.value = 'http://myopenid.com/url';

-- Allen


> 
> - Dave