Issues related to authentication and authorization in a centralized workflow

[Marcin Zajaczkowski]

Thank you guys for your answers!


On 2009-01-08 17:49, John Arbash Meinel wrote:
> Marcin Zajaczkowski wrote:
(...)
>> I'm experimenting with a migration from Subversion to Bazaar, because I
>> see advantages of distributed VCS. Nevertheless it's important for me to
>> stay with a centralized workflow.
>> The main problem I meet is related to authentication and authorization.
>> In current environment there is an authentication based on LDAP and an
>> ability to specify who has the rights to access to given project.
> 
> So in general, it seems like you want 3 values for a given user
> 
> 1) Completely hidden
> 2) Read only access
> 3) Read write access
> 
> It also sounds like you are doing this on a "per project" basis (versus
> per-branch, or some other dividing line).

Yes. Subversion gives us an ability to specify access at branch 
(directory) level, but usually it's enough to give generic access to the 
whole project for a development team.

> To start with, I would make sure that each "project" has its own Bazaar
> repository. There are other ways to group it, but that is the easiest.
> 
> Going out from there, there are a few possibilities.
> 
> a) As mentioned elsewhere, there is at least some amount of integration
> between HTTP(S) access (via Apache) and LDAP authentication. I don't
> know that Apache is smart enough to be able to use custom fields in LDAP
> to indicate access.

In fact it's only important to have authentication using LDAP (user - 
password). Custom fields in LDAP could be tricky, but access definition 
for project could be done via text ini files like mentioned in Marius' post.

> b) Use bzr+ssh with a custom script, similar to "bzr_access". This is,
>    essentially, how Launchpad does it. (Technically they start with a
>    custom SSH server.)
> 
>    Basically, you use ssh's ability to restrict connections to always
>    run a specific program. In the 'bzr_access' example, we also used the
>    ability that you can customize this program based on the ssh key
>    used.

The problem in my case could be with "authorized_keys". In LDAP 
authentication there is user-password pair and I don't know would it be 
easy to write "bzr_acess" script for password authentication via SSH.

>    Right now, bzr_access uses a config file (bzr_access.conf) to
>    determine the read/read-write ability for different users. This would
>    need to be changed to contact your LDAP server and query it.
> 
>    The easiest way to get it working *right now* would be to use a
>    custom group/user for each project (one with -readwrite and one with
>    -readonly access), and then have the custom program seteuid() to the
>    appropriate user after connecting.

Full SSH access to the file system could be quite dangerous. User with 
RW rights to the project could (even accidentally) delete the whole 
repository (with all the history).
Is there a simple way to set bazaar via ssh without allow to perform any 
other (non Bazaar one) operation (like direct access to a file system)?

I have seen bzr_ssh_path_limiter script, but it also uses keys. On the 
other side "bzr serve" itself doesn't allow (AFAIR) to any additional 
authorization (RO or RW for everyone). And here comes ACL specification...

>    However, there is also this spec around:
>      http://bazaar-vcs.org/Specs/ACLTransport
>    Which sounds like it would fit quite easily with what you want. At
>    the moment, nobody has stepped forward to implement it, because it
>    hasn't gotten high enough on someone's priority list.
> 
>    I honestly think it would take only a couple days to really
>    implement, and I would be happy to mentor someone who was interested
>    in doing so.

 From the description I understood that it would allow to have more 
granulated authorization using "bzr serve". It would eliminate a 
necessity of using various wrappers to achieve that. As a first version 
it would be probably enough to have only per project/repository access 
control.
I think it would be very helpful for people migrating from centralized 
repositories.


Regards
Marcin