Hello, Sergei.
Sergei said:
> Well, each user has it's own 'metadata', like a fullname, nickname,
> email and etcetera. Some of them a widely-used, some are auth-backend-
> specific, like OpenID url in case of OpenID or DN in case of LDAP.
> When talking of multy-auth apps, one should take care of that and
> decide of a common subset of these fields to have access to them
> independenlty from the auth source.
>
> The next question is where to store these fields. Why bother? Imagine
> you store some entities in the database, and You wand them to have an
> 'owner'. A most common approach is to have a relation to the user's
> table - that's simple when You have only built-in SQLAlchemy auth.
> What should one do if having both SQLAlchemy and LDAP users, or maybe
> even OpenID ones? The simplest solution is: at first 'external' login,
> fetch the required fields, create a 'dummy' user account and then link
> other entities to it. On each next login, just update the fields from
> external source, should it be OpenID SREG or LDAP keys. You won't keep
> all this data in every table, sure? ;) And You won't query the
> external source on every page render.
Yes, it sounds sensible. Another common alternative would be to provide a
registration form for LDAP and OpenID users in order for you to gather all the
metadata available in the back-end and ask the user to provide the missing
data (if any) -- of course, unlike normal registration forms, you wouldn't
request a password for the account. I think both options are basically the
same thing.
On the other hand, I'd like to point out that since LDAP and OpenID back-ends
return user Ids that are special, it will cause interoperability problems.
What you could do, is:
1.- Ask new LDAP/OpenID users to choose a username for the site, which then
you'll store in your users table (again, with no password).
2.- On each login, replace the LDAP Distinguished Name or the OpenID URL/XRI
with the user's name that you have in the database.
You wouldn't have to worry about it if you were using authentication back-ends
which return the same kind of usernames, but here the three back-ends return
three different things.
> And, well, You'll probably want to promote some rights for these
> external users, via groups or roles. Will You store them in LDAP?
> Quite a good idea sometimes (great for a some corporate sites, tightly
> integrated with other IT staff), but won't work with OpenID.
Plus, there's no repoze.what LDAP plugin yet :)
> And, well, there could be sources with no extended data, like
> 'login:password' DSV files (htpasswd-like) - no gecos, no groups/
> roles.
Actually that's another thing, it's not authentication, it's just user
metadata.
Users' metadata don't necessarily have to be stored in the same source that
has the data required for authentication. It's just a coincidence in LDAP,
OpenID, etc.
> (well these were not questions, but an invitation to a discussion --
> as for me, I'll cache the data in a database, mixing 'real' users with
> 'external' and keeping 'external' users from logging in locally) But
> I'll appreciate other opinions!
I'd treat them all like just one kind of users. They would all have a record
in the users table, which would look like this:
- user_name (PK).
- authn_backend ("openid", "ldap", "db").
- authn_key.
- email.
- full_name.
- ... the other columns...
Where the value of "authn_key" will depend on "authn_backend":
- "openid": An URL or an XRI.
- "ldap": The Distinguished Name.
- "db": A string which represents a password (most likely in the form of a
hash).
HTH,
--
Gustavo Narea <xri://=Gustavo>.
| Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about |
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
