I've been working on an Identity and Access control framework for
TurboGears. This will provide you with the following features for your
TurboGears-based Web applications:
* A require decorator that checks the current user's permissions and/or
group membership
* A SecureResource base class from which you can derive controllers --
to alleviate having to specify the same permission requirements for
every exposed method.
* An IdentityFilter to scour the incoming request and associate it with
a User
* A basic Identity model including classes for User, Group, and
Permission. This model includes a plug-in for the IdentityFilter so that
everything "just works".
Right now I'm stumped on some of the features of the Admin UI. But I'm
increasingly thinking that I should polish up the framework and release
it without the admin UI to get some feedback.
Just a few details:
* Your Identity is stored as a signed cookie. So there's no need for
sessions unless your app uses them. Plus, because the cookie is signed
by the server (SHA1 hash of identityID, expiration, and a "secret token"
provided by the Identity model), there's *less* worry about users faking
their identity.
* The IdentityFilter uses InternalRedirect exceptions within CherryPy to
access a login form that you expose from one of your controllers.
Ultimately, the Admin UI will include a default login form.
* The framework intends to, but does not currently, support HTTP auth.
* The Identity framework takes Ajax into account by returning pages
using appropriate status codes (403 Forbidden). Plus, because you're
going through the TurboGears expose decorator, if you requested JSON
output, you'll really get it. The JSON output contains meaningful fields
you'll be able to trigger off to "do the right thing".
* In the default model, Permissions are associated with Groups
(many-to-many) and Users are associated with Groups (many-to-many). So
it is not possible to directly assign a permission to an individual
user. Yes, this is a little more than necessary for small user
communities but absolutely essential as your community grows (speaking
from the experience of having done Identity Mgmt and Access Control
audits for large clients).
Jeff
--
Jeff Watkins
http://metrocat.org/
pierrebai wrote:
I saw there is a ticket open for authentication / authorization. I also
read that CatWalk has no security for now.
What I propose is not a design by simply a standardize high-level
function API to check authorization. I currently use the following:
def checkRole(role='admin'):
# checkRole implementation.
In simple word, a checkRole function taking a string for the role, by
default 'admin'. How this is mapped internally, how role and identities
are implemented, represented and accessed is hidden from the API.
Currently checkRole() sets a turbogears flash error then redirect to
the login page ("/" on my site). Maybe checkRole could be extended to
be:
def checkRole(role='admin',error='You are not
authorized.',redirect='/')
# checkRole implementation.
A few points of discussion:
- How to plugin the checker? By setting a pre-defined tg variable?
- Alternative check result: specifiable exception, callback?
- Check without raising error? This currently can be done by a try:
block.
I also think separating authentication API and authorization APi is a
good thing, although a given implementation can (and probably will)
make them common internally for obvious reasons.
