identity info in a config file

[Kevin Horn]

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

[Paul Volpato]

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

I certainly hope this isn't where TurboGears is going - when it does
that why not just call itself Zope3 2? If this is the eventual plan,
I would say make it entirely optional - and certainly don't make it
xml. If people wanted to play with config files they'd do java web
development :)

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

It seems like a useful use case at first glance - but do you really
want someone who doesn't understand how the system works setting the
security on it?

I think that the security should really be done by the developer. The
idea that an admin can sit down in front of a foreign system and start
reassigning permissions is not realistic.

[Elvelind Grandin]

I have to somewhat agree with Paul. Setting the permissions for the
system is the developers jobb not the admins. The admins handles the
users and adds them to the correct groups depending on what their
permissions should be.

--
cheers
elvelind grandin

[Game_Ender]

Would it not be easier to have the information to be stored in the
database and create and some kind of "Users and Groups" tool for the
toolbox? The text based config file would work on some level, but with
the database you would keep the permissions with the data they are
protecting/controlling. So that any back up of the database will also
take the proper permissions with it.

More on the web based Identity manager. If it is created then that
tool can then be integrated into other Turbogears based projects that
need a users/groups/permissions system and want a web interface to it.
Things like photo galleries, forums, CMS packages all need a good web
based system for this. It would be valuable if each developer would
not have to reinvent this wheel.

[Jorge Godoy]

"Kevin Horn" <kevin...@gmail.com> writes:

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

I believe that the configuration file for parts of the code will be there only
when FirstClass arrive (WSGI version of TG)...

--
Jorge Godoy <jgo...@gmail.com>

[Jorge Godoy]

"Paul Volpato" <paul.v...@gmail.com> writes:

> I certainly hope this isn't where TurboGears is going - when it does
> that why not just call itself Zope3 2? If this is the eventual plan,
> I would say make it entirely optional - and certainly don't make it
> xml. If people wanted to play with config files they'd do java web
> development :)

Unfortunately, as of today, if you want to let your clients free to define
permissions and access restrictions you have to edit the code (or let them do
it).

I prefer users editing config files (for which I can easily make a web
interface...) rather than code.

> It seems like a useful use case at first glance - but do you really
> want someone who doesn't understand how the system works setting the
> security on it?

Sometimes yes. Specially when you group functionalities and they are your
client's business, not yours. Imagine that you deployed your application and
two years later your client says: "Now we have a new management function on
the company that needs full access to finance data, no access to technical
data, etc.". Why wasn't he able to define that by saying something like:

[finance]
read = ..., new_group
write = ..., new_group
delete = ..., new_group
update = ..., new_group

? Easier than you having to go there (where is "there"? in the other office?
another city? another country?) to do that. After all, after two years you'll
want to take a look at your client and see how the system is solving their
problems, what else you can sell them, etc.

> I think that the security should really be done by the developer. The
> idea that an admin can sit down in front of a foreign system and start
> reassigning permissions is not realistic.

It happens on several CMSs and several ERPs. I believe it works.

--
Jorge Godoy <jgo...@gmail.com>

[Jorge Godoy]

"Elvelind Grandin" <elve...@gmail.com> writes:

> I have to somewhat agree with Paul. Setting the permissions for the
> system is the developers jobb not the admins. The admins handles the
> users and adds them to the correct groups depending on what their
> permissions should be.

And what about commercial systems? You'll tell your client that he's tied to
you to a simple task as that of saying who can and who can't access what? I
mean, he'll have to pay your hourly costs for this task all the time something
changes? And he'll have to "rethink" if the existing permissions apply always
when he hires a new employee? (Remember: he'll want to avoid costs with that,
so security *will be* sub-optimum...)

--
Jorge Godoy <jgo...@gmail.com>

[Jorge Godoy]

"Game_Ender" <jli...@gmail.com> writes:

> Would it not be easier to have the information to be stored in the
> database and create and some kind of "Users and Groups" tool for the
> toolbox? The text based config file would work on some level, but with
> the database you would keep the permissions with the data they are
> protecting/controlling. So that any back up of the database will also
> take the proper permissions with it.

I've been thinking about that as well... But the best thing with that is that
you could define some kind of grouping for your classes and methods and
protect them as a whole. Or you could simply classify all of your methods
with a description (from the docstring? updated automatically?) on the
database so that people have 100% granularity there.

> More on the web based Identity manager. If it is created then that
> tool can then be integrated into other Turbogears based projects that
> need a users/groups/permissions system and want a web interface to it.
> Things like photo galleries, forums, CMS packages all need a good web
> based system for this. It would be valuable if each developer would
> not have to reinvent this wheel.

Maybe, as mentioned before, some callables to get those information are
enough. Then you'd just have to apply your decorators with such callables.
No more work than you do today and your callables code is 100% reusable (and
could become a product by itself, a kind of "plugin").

--
Jorge Godoy <jgo...@gmail.com>

[Alberto Valverde]

On 31/03/2006, at 14:24, Jorge Godoy wrote:
> And what about commercial systems? You'll tell your client that
> he's tied to
> you to a simple task as that of saying who can and who can't access
> what? I
> mean, he'll have to pay your hourly costs for this task all the
> time something
> changes? And he'll have to "rethink" if the existing permissions
> apply always
> when he hires a new employee? (Remember: he'll want to avoid costs
> with that,
> so security *will be* sub-optimum...)
>
>

I agree with Jorge here. The security policy should be the
administrator's responsibility, not the developers. For example, in
unix (be it plain ol' PAM or a fancy ACL system like SELinux) no line
of code needs to be written to change the permissions or capabilities
of a given user, just use the system tools for the job which any
sysadmin can do.

My 2c, Alberto

[Elvelind Grandin]

Perhaps this depends some on how you set up the groups and permissions
to start with. I never give any specific user access to anything.
Every permission is bound to a group. So that the users permission
just depends on which groups they are part of.

--
cheers
elvelind grandin

[Jorge Godoy]

"Elvelind Grandin" <elve...@gmail.com> writes:

> Perhaps this depends some on how you set up the groups and permissions
> to start with. I never give any specific user access to anything.
> Every permission is bound to a group. So that the users permission
> just depends on which groups they are part of.

I do the same. But even so, you are hardcoding groups. And if you need an
extra group for a new situation you didn't have while you developed the
application, you're again needing to edit code.

--
Jorge Godoy <jgo...@gmail.com>

[Paul]

I think if you look at the current system it is as 'configurable' as
you want without changing code.

You can simply set 'permissions' on each method/resource (in the code).
Then if the client has a 'new' role to fill, they can (through a
catwalk like facility) simply create a new group with the needed
permissions.

This is how Zope 2's security model works and it has been used to make
countless CMS systems :) (and a few ERPs as well).

What do you think?

[Kevin Dangoor]

On 3/31/06, Jorge Godoy <jgo...@gmail.com> wrote:
>

Configuration will certainly be a little different in FirstClass
(focusing more on application-oriented config, rather than
path-oriented config).

Identity, as it is today, is very simple to use, and that's a good
place to start. What I'd be interested in seeing later is an
incorporation of RuleDispatch, which will allow much more arbitrary
collections of rules to determine what people can access -- going well
beyond just users and groups. ("Group A can access this resource
Monday-Friday only")

I don't have an immediate use case for this myself, but if someone
does we can certainly talk about it.

Kevin

[Jeff Watkins]

On 31 Mar, 2006, at 4:28 pm, Jorge Godoy wrote:

And if you need an

extra group for a new situation you didn't have while you developed the

application, you're again needing to edit code.

In my experience, when you need a new group for a new situation it has almost always involved new code surrounding either the new group or new situation. Unless you dramatically failed to design the original code, it shouldn't change (or at least not change significantly) only the new code should "change".

If you look at the design of many systems, functions have specific required permissions: want to mount backup media, you must have the mount-backup-media permission; want to reboot the system, you must have the power-down-system permission; want to change the disk quotas, you must have the modify-system-quotas permission; etc.

These permissions get combined into groups for convenience: Admin has permission to mount-backup-media, power-down-system, modify-system-quotas, etc. You then assign users to these groups. In your straw man argument you have clearly not distinguished the permissions enough. If you assign sufficient granularity to your permissions, you'll NEVER edit code only modify group membership.

Identity management is like any other complex issue: you have to take time to really think about it before writing a line of code. If you just hack it together as you go, it won't work long term.

Initially, when I was designing TG's Identity framework, I considered not even allowing a check for a particular group. But the fact is for a quick and dirty project, all you need is group checks. And Kevin convinced me to target the low end of the spectrum as well as the high end.

Here are some issues on which I think someone's effort could be well spent:

* Collect all the permissions and groups referenced in a project (ala Admi18n Collect Strings)

* Automatically create collected permissions and groups

* Toolbox UI for managing Users, Groups, and Permissions (keep in mind that adding permissions isn't very useful if the code doesn't reference them)

* Visitor-facing UI for managing his profile

* Visitor-facing UI for registration

* Email validation of visitor registration (e.g. you register, TG emails you a confirmation, you reply, your account is activated)

I'd be happy to work with (or advise more likely, because I don't have a lot of time these days) someone to make these things happen.

--

Jeff Watkins

http://newburyportion.com/

"Computers are like Old Testament gods; lots of rules and no mercy."

-- Joseph Campbell