I'm setting up a hosting proof of concept, and trac uses web authentication for users. Anybody got some ideas on how to tie into our account system for this?
On 11/19/06, Jesse Keating jkeating@redhat.com wrote:
I'm setting up a hosting proof of concept, and trac uses web authentication for users. Anybody got some ideas on how to tie into our account system for this?
-- Jesse Keating Release Engineer: Fedora
<Location /path> Options ExecCGI AuthType Basic AuthName "You want in? GET A PASSWORD!"
Auth_PG_host db1 Auth_PG_port 5432 Auth_PG_user apache Auth_PG_pwd ASKMEFORPASSWORD Auth_PG_database fedorausers Auth_PG_pwd_table person Auth_PG_uid_field username Auth_PG_pwd_field password
Auth_PG_encrypted off
Require user jkeating mmcgrath # or # Require valid-user
</Location>
FWIW, a final implementation would optimally be a little more complicated than this: . It should only give access to people whose accounts are in 'approved' status (not many aren't, but still...) . It should only give access to people who have approved access in a particular group (e.g. 'tracusers' in this case) so that we can use the account system to authorize users...
-- Elliot
<Location /path> Options ExecCGI AuthType Basic AuthName "You want in? GET A PASSWORD!"
Auth_PG_host db1 Auth_PG_port 5432 Auth_PG_user apache Auth_PG_pwd ASKMEFORPASSWORD Auth_PG_database fedorausers Auth_PG_pwd_table person Auth_PG_uid_field username Auth_PG_pwd_field password
Auth_PG_encrypted off
Require user jkeating mmcgrath # or # Require valid-user
</Location>
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
On 11/19/06, Elliot Lee sopwith@gmail.com wrote:
FWIW, a final implementation would optimally be a little more complicated than this: . It should only give access to people whose accounts are in 'approved' status (not many aren't, but still...) . It should only give access to people who have approved access in a particular group (e.g. 'tracusers' in this case) so that we can use the account system to authorize users...
-- Elliot
This actually isn't terribly difficult to set up with pgsql but we'll have to alter our database a bit. If the time comes and the new accounting system isn't ready we can make these alterations.
-Mike
On Sunday 19 November 2006 21:31, Elliot Lee wrote:
FWIW, a final implementation would optimally be a little more complicated than this: . It should only give access to people whose accounts are in 'approved' status (not many aren't, but still...) . It should only give access to people who have approved access in a particular group (e.g. 'tracusers' in this case) so that we can use the account system to authorize users...
I think this sounds pretty sane. Getting approved for trac should be as simple as having the CLA complete, or something similar. I think its a good policy discussion to see if we want to involve the CLA for project hosting. I know its stifled some of the work in Kadischi according to some of the users that would like to contribute but don't want to go down the CLA route. Also Trac can be used pretty easily in anonymous mode.
On Nov 20, 2006, at 8:11 AM, Jesse Keating wrote:
On Sunday 19 November 2006 21:31, Elliot Lee wrote:
FWIW, a final implementation would optimally be a little more complicated than this: . It should only give access to people whose accounts are in 'approved' status (not many aren't, but still...) . It should only give access to people who have approved access in a particular group (e.g. 'tracusers' in this case) so that we can use the account system to authorize users...
I think this sounds pretty sane. Getting approved for trac should be as simple as having the CLA complete, or something similar. I think its a good policy discussion to see if we want to involve the CLA for project hosting. I know its stifled some of the work in Kadischi according to some of the users that would like to contribute but don't want to go down the CLA route. Also Trac can be used pretty easily in anonymous mode.
Thinking about it some more (now that I realized it's in the context of hosting projects) - you're going to want to have a separate account system group for each hosted project.
I don't know whether it's the CLA or something else, but you should work with RH Legal to make sure that there is some sort of legal agreement in place between the project contributors and Red Hat to define the relationship.
Best, -- Elliot
On Monday 20 November 2006 18:43, Elliot Lee wrote:
Thinking about it some more (now that I realized it's in the context of hosting projects) - you're going to want to have a separate account system group for each hosted project.
Why would that be? At least with trac, all fedora users are treated the same as anonymous, but you could get your name attached to a bug (and thus emails) and wiki changes. Account privilege escalation can be done within the Trac instance itself, through the webadmin tool. Why would we need a different account system? Why wouldn't the Fedora account system work and just allow any user that has CLA signed to create a project or login to participate with a name to an existing project?
On Nov 20, 2006, at 10:07 PM, Jesse Keating wrote:
On Monday 20 November 2006 18:43, Elliot Lee wrote:
Thinking about it some more (now that I realized it's in the context of hosting projects) - you're going to want to have a separate account system group for each hosted project.
Why would that be? At least with trac, all fedora users are treated the same as anonymous, but you could get your name attached to a bug (and thus emails) and wiki changes. Account privilege escalation can be done within the Trac instance itself, through the webadmin tool. Why would we need a different account system?
(To recap, I suggested a different account system _group_, not an entirely different account system.)
Why wouldn't the Fedora account system work and just allow any user that has CLA signed to create a project or login to participate with a name to an existing project?
I think that works within the context of Fedora as a whole, but moving into hosted territory means you have to adopt more of a sourceforge mentality, where your job is to give as much control as possible to the project owner, and let them make decisions such as who can participate. In order to let each project owner make access decisions independantly, you would need a separate account.
It sounds like trac has some 'webadmin' thing for controlling people's access - I think it's a bad idea to go with that. Properly tying trac into the Fedora account system means making it so that full control of both authentication & authorization is done through the FAS. In the long run, it'll be a lot nicer to be able to go to one place to control people's access levels for everything. (Not to say that FAS v1 is the right way to do it, just suggesting a good goal for the future :)
Best, -- Elliot
On Tuesday 21 November 2006 20:34, Elliot Lee wrote:
I think that works within the context of Fedora as a whole, but moving into hosted territory means you have to adopt more of a sourceforge mentality, where your job is to give as much control as possible to the project owner, and let them make decisions such as who can participate. In order to let each project owner make access decisions independantly, you would need a separate account.
I'm still not so sure you would. For a source repo, there would be a new group, and the existing user who is the admin for a project would be made the admin of this group. (S)He could then approve/deny requests to join the source group for write access.
It sounds like trac has some 'webadmin' thing for controlling people's access - I think it's a bad idea to go with that. Properly tying trac into the Fedora account system means making it so that full control of both authentication & authorization is done through the FAS. In the long run, it'll be a lot nicer to be able to go to one place to control people's access levels for everything. (Not to say that FAS v1 is the right way to do it, just suggesting a good goal for the future :)
This _may_ be possible in the future, however the only real authorization that we need to set in Trac is the initial admin. The trac webadmin is mostly for setting up urls and project summaries, and ticket components, milestones, etc.. All of this is highly trac instance specific. There _is_ some management of who can open/close bugs I do believe, and who is a default owner of bugs, but again its all instance specific. I think for the first instance of Fedora Hosted Projects this would be perfectly serviceable and if problems arise we can look at fixing them, or more tightly integrating trac with FAS v2 for Fedora Hosted Projects v2.
infrastructure@lists.fedoraproject.org
-
Elliot Lee -
Jesse Keating -
Mike McGrath