Add an authorization layer

[gregsohl]

This great web front end would be even better with an authorization layer on it. This could encompass simple RW access and possibly extend with a hook for handling branch and folder access.

Has anyone done something like this for it?

[otac0n]

Well, for now, I was allowing people to use IIS's built-in authorization and authentication mechanism. You can add <path> elements to the web config to limit specific URLs to specific roles.

I don't have a great solution for those who don't want to use the built-in auth.

[gregsohl]

That would work for basic repo authorization. What I'm toying with right now is using the Gitolite permissions configuration file syntax and build on that. That would mean that WebGitNet directly would do auth for repos for RW access. I'm also looking to build a git hook, also in C#, to process ref-based permissions like Gitolite does. That would compliment WebGitNet well, I think.

I have the Gitolite permission wrapper done and tested. Just at a point of integrating it with WebGitNet now. Will have it basically running by end of day Monday. I'll do the git hook next, which won't be tough.

[otac0n]

Well, I'd love to see what you come up with.

[revgum]

Looking forward to hearing more about permissions enhancements here.. I use the IIS integrated authentication for viewing the web pages, and then a user local to the webserver for the actual git repositories so my users aren't passing their own credentials during a git clone or push/pull..

[gregsohl]

I have the authorization layer added and tested. Tests included using the web site, Git Extensions and git from the command line. I'm planning to put it in production shortly. I'll push the code to my fork for review yet this week.

The implementation is provider oriented. I've written a Permissive auth provider and a Gitolite auth provider. The Permissive allows everything. The Gitolite reads the gitolite.conf file and provides permissions based on it. The providers are implemented in new project, WebGitNet.AuthorizationProviders. There is an interface for them in WebGitNet.SharedLib/Authorization/IAuthorizationProvider.

Note - I could use someone to look at the Castle Windsor code I used in global.asax.cs to load the auth provider. I'm no Castle Windsor expert and I'm wondering if it could be done better. I especially want to avoid the property injection I'm doing and have that be constructor injection instead - it would be cleaner.

The selected provider is controlled by a web.config option "AuthorizationProvider". Available values are

• Gitolite
• Permissive (default)

The Gitolite config handler is implemented in new project GitoliteConfig and has companion project GitoliteConfigTest, with extensive unit tests against the permissions management provided by GitoliteConfig. I've not implemented ALL of the Gitolite config capabilities, but it is pretty thorough and appropriate for this environment. I'll document what I do have and a slight behavioral deviation to make things simpler.

Authorization work is provided by WebGitNet/Authorization/CustomAuthorization. This derives from AuthorizationAttribute and is registered as a filter in global.asax.cs. It also provides a few public methods for permissions testing. While functional, I would say I'm not totally happy with the implementation. Too much path peeking. I think it can be simplified.

Domain based logins are supported and must be specified in their entire form in the gitolite.conf file .

I added a web.config option "BrowseList" with the following optional values:

• AllWithLinks - Default / current behavior - show all repositories with links
• AllLinkWithPermission - Show all repositories, only link those the user has permission to
• OnlyWithPermission - Only list the repositories the user has permission to

I added display of the logged in user to the header, on the right side of the breadcrumb bar. This was helpful with testing and it just looks nice :).

Pending:
Write a git hook to support more detailed permissions provided by the Gitolite config. The gitolite config is ready for this. Just need the hook now, so that different kinds of Pushes and branch access can be restricted.

[gregsohl]

Auth layer continues to work well. Will let all users in tomorrow.

I'm almost ready with my companion Update hook to handle additional permissions, such as Create Ref, Delete Ref, prevent non-linear push, etc.

[otac0n]

👍

[gramx]

I was looking at implementing something like this, I have installed the latest copy but I don't see the (new auth) project or web config value (AuthorizationProvider) for this added security. I am new to both Git and Git hub, are open/active issues not included in the latest source (7 months ago)?

[gregsohl]

I have an authorization layer fully implemented and in production using
GitOLite style config. Should get some time this month to get it
Pull-Request ready. I also have additional Git filters implemented in .NET
for filtering various types of requests.

Greg Sohl
http://www.cwi-websoft.com/blog

On Wed, Dec 4, 2013 at 3:42 PM, Gram notifications@github.com wrote:

I was looking at implementing something like this, I have installed the
latest copy but I don't see the project or web config value for this added
security. I am new to both Git and Git hub, is open issues something that
is not included in the latest source (7 months ago)?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/64#issuecomment-29848586
.

[gramx]

Thanks Greg ill take a look should be helpful. 👍