I've seen mentioned several times on this list that an eventual goal of the identity system in TurboGears is to be able to specify the required groups, permissions, etc. for access to a resource in a config file.  This would allow an administrator, rather than a developer, to set security policy.  I have not seen any ideas on how this would actually work, though.  Is anyone actively working on this?  In case the answer is no, here are some ideas that I just had...

DISCLAIMER: I have not even looked at the code for the @identity decorator and have no idea if the following would work, much less whether it's practical to implement, or even a good idea.  If I'm totally off base on this, please just let me know.  I won't take offense :)

So I was looking at the examples over in the wiki (http://trac.turbogears.org/turbogears/wiki/IdentityManagement) and I noticed that the @ identity.require() decorator can take not only parameters (like @identity.require(group="admin") ), but also callables (like @identity.require( identity.in_group( "admin" ) ) ).  [I am presuming that this is still the case...that article looks like it is in a state of flux.]  If this is the case, then would it be possible to have a callable that can be passed to the decorator which would direct the decorator to use a config file?

Something like:
@identity.require( identity.check_config_file( "identity.cfg" ))

The decorator could then check the config file for the appropriate authorization information.  The config file could maybe look something like this:

[resource_name]
in_group = "admin"
has_permission = "edit"

...or something of the sort.

AND and OR type authorization could possibly be handled by using AND/OR in the string value for the config option, like:

[resource_name]
in_group = "admin OR superuser"
has_permission = "edit"

Like I said earlier, I haven't delved into the inner workings of the identity system, but it seems that, at least for the user (TG app developer) this would allow the use of a config file for authorization data without having to relearn a whole new system.

Potential problems/limitations:
- I have no idea how hard/easy this would be to implement
- Performance could be a problem
- Might run into problems with applying one set of auth info to an entire controller
- The example config syntax I have suggested above is quite simplistic, and might not be able to cover all use cases.  A better one probably could/should be devised.
- Config file could get awfully verbose
- AND/OR could be tricky across auth types...for example, how would say "authorize if the user is an admin OR has the edit permission"

Anyways, this is just an inkling of an idea, and I haven't put more than 10 minutes thought into it.  I'm hoping though, that it will prompt a discussion among the really smart people around here, so that they can come up with a better idea than I can. :)

Of course, it's completely possible that someone out there already has a better idea and will commit it to the repository any minute now...

Please share your thoughts...

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to