support for public key based security?

[gitblit]

Originally reported on Google Code with ID 106

Are there plans to support public key based security (in addition to userid/password
login)?

https://help.github.com/articles/generating-ssh-keys

Thanks

Reported by gliptak on 2012-07-11 13:07:06

[gitblit]

If you mean SSH, then no.  If you mean https client certificate authentication, then
perhaps.  I'm not opposed to SSH, I just have no interest in implementing it.

Reported by James.Moger on 2012-07-11 13:19:52

[gitblit]

I would like to see some easy means of pushing a public certificate into the server,
and being able to avoid typing in a password on the command line. Thanks

Reported by gliptak on 2012-07-11 22:33:34

[gitblit]

So I'm not entirely sure if I should open a new issue for an enhancement or not but
for now I will add to this one. I would like to see the possibility for client certificate
authentication for the web interface and git client if possible with perhaps user information
stored in something like an ldap server. The question I have since I am still trying
to understand everything and am new to java web applications is if it would be as simple
as a new wicket filter or an extension to IUserService? I am willing to make an attempt
at it, although I won't make any promises, if I could get a decent overview of things
and where to start looking in to things. Thank you for your time.

Reported by andersonkw2 on 2012-09-19 01:06:02

[gitblit]

You would have to implement a servlet filter which would intercept all incoming requests
to grab the certificate from the request (I actually have no idea at the moment how
client certs work - is it a request header field?).

We will need an implementation of javax.servlet.Filter and we will have to modify the
web.xml file to make this filter the root filter for the app and then have Wicket next
in the filter chain.  As for the user service, we shouldn't need a new one but we will
need some way to map a cert to a user which probably will require adjusting the user
services.

I've been wanting to revise the filter chain so this is good timing.

Reported by James.Moger on 2012-09-19 12:20:08

[gitblit]

So I have made an attempt at this but not successfully yet. So the client cert is requested
and passed in a http attribute (javax.servlet.request.X509Certificate). 

So I am running gitblit in tomcat with tomcat set to require a certificate. After adding
the filter to the web.xml I am able to print out the distinguished name of the certificate
that is passed to the server. I would think using the distinguished name of the certificate
as the username would be best as it uniquely identifies the individual and then leave
the displayName up to the user or some other source. That would eliminate the need
to modify the user services I believe. 

Assuming I pass a client certificate to the server which proves to be authenticate
and extract the distinguished name out of the request, how do I then say to the main
servlet that the user is authenticated by the filter and automatically log them in
to the web interface and authenticate git actions (push,pull,branch,etc.)? I see that
there is an authenticate(username,password) method but how would it been done strictly
based off of the certificate without a password? 

Reported by andersonkw2 on 2012-09-26 00:05:32

[gitblit]

We'll need a new method in the user services to authenticate the certificate.  Something
like the authenticate(cookie) method that exists.

It is not clear to me if the cert is to be used in a public key/private key scenario
or if it is a more sophisticated cookie.  If the latter then perhaps we can take the
SHA1 of the entire cert and store that in a user field.  It also seems that we may
want to store several certs (or cert hashcodes) per user account.  Kinda like how GitHub
allows you to upload multiple SSH keys.  Alternatively we could base64 encode the cert
and store it as a field in a user.  Last resort would be store the cert to a file...
but then we'll run into trouble with federation.

How do you configure the git client to send the cert?  Are you modeling this based
on an existing implementation?

Reported by James.Moger on 2012-09-26 00:51:48

[gitblit]

I will look in to adding a new method to authenticate the certificate. The authenticate
method could take the certificate object, validate it, and return a user model similar
to what the cookie and password method do now from my understanding. 

This is only my interpretation but I believe it is based off of a public/private key
pair but they rarely are separated. I also think it would only be necessary to store
the distinguished name of the certificate. An example DN could be cn=unique identifier
or even email(username),ou=Marketing,o=Some Big Organization,l=Some State,st=No Where,c=us.

Ultimately if you are passed a certificate with a certain distinguished name and it
is validated by a certificate authority that you have set as trusted for your installation
it certifies that the user is who they say they are and that they are the only person
with that DN. With that being said if you only store the DN for the certificate when
it comes time for a certificate renewal the user can still access the server because
the DN will have remained the same and the new certificate should pass all validity
checks.

Also the approach I am trying to accomplish is more towards SSL X509 client certificates
than it is ssh key pairs. With each DN being unique like a username would it fit better
as a username with the display name being the user? Or perhaps the first cn entry of
the DN being the username? So a DN of cn=bob.smith,ou=developers,o=major corp,l=fairfax,st=virginia,c=us
would have a username bob.smith.

The git client can be configured for SSL client certificates with the http.sslCert
and http.sslKey option. What do you mean by existing implementation? Existing applications
perhaps? If so then yes. For my environment we have a policy to enable SSL certificate
authentication on all applications. We run our own certificate authority and pass out
certificates to everyone to authenticate them to applications. This has the advantage
of standardizing the authentication and freeing people of having to remember more passwords.

I appreciate all of the feedback thus far. This is all new to me but I decided the
best way to learn is to jump in and try to get something working. :)

Reported by andersonkw2 on 2012-09-26 02:20:18

[gitblit]

Ok, I think I get it.

I'm wondering if Gitblit should generate a client certificate and that cert could then
be downloaded by the user to their machine and configured using http.sslCert.  Essentially,
make Gitblit a CA for itself.

It is not what you need, but for those who want client certificate auth with minimal
fuss, it might make things easier.  This would be analogous to GO creating it's own
self-signed cert on first execution so that you can start with https security right
away.

Or perhaps I still don't have a complete understanding here.

Reported by James.Moger on 2012-09-26 12:06:11

[gitblit]

Are you still working on this capability?

Reported by James.Moger on 2012-10-19 18:35:17

[gitblit]

I am still working on at the very least getting basic client certificate authentication
working. I've been unable to dedicate any substantial amount of time to it right now
though so it is taking longer than expected. 

Reported by andersonkw2 on 2012-10-19 19:13:26