External database query for authentication (RBAC)

[BoleroDan]

We're looking to use Web2py as our framework for developing a couple applications. However we already have a massive database for our research project, and almost all of the information is integrated into this database (including usernames, passwords, group names etc) so it would be nice to have web2py just access this database for username/password/group membership authentication.

I'm hoping this can be integrated into Web2Pys already existing RBAC management as that would be nice. I also noticed that a lot of the other alternative login methods still require web2pys local auth_user table and stores the remote credentials locally in this table. Is this needed by design or can this be skipped? I'm just thinking its not needed for us to have duplicate login information across two databases. I just need Web2py to query our database, get the credentials authenticated and what group they are in (so i can control access to functions on web2py based on their group).

Thanks for any heads up on the matter.

[Massimo Di Pierro]

In the scaffolding app there is a file db.py which defines for you everything you need for RBAC. If you do not want to use this built-in functionality simply delete the file and use your own API. There is nothing that really depends on it.

[danto]

so, I think they can't use auth.methods without defining auth tables first (kind of obvious?)

2012/5/10 Massimo Di Pierro <massimo....@gmail.com>

[Massimo Di Pierro]

True. gluon/contrib/login_methods only work with auth.

[Michele Comitini]

You can create a new login_method while keeping the auth tables as usual.
The login method will work on the legacy db.
The auth table will contain user data in another db, can be sqlite or
anything else supported by DAL.
Indeed web2py auth tables *do not need to contain secrets*, those can
be kept on the legacy db.
This is pretty much how all login_methods that delegate authentication
to third parties work.

If you have more than one application to be managed that way in can be
useful to create an authenticator application that does all the work
of connecting to the legacy db and do proper authentication, and
provide authorization (groups or whatever) info back to the consumer.
The other applications can be CAS consumers to the authenticator, the
CAS producer, application.

mic


2012/5/11 Massimo Di Pierro <massimo....@gmail.com>: