On Wed, Jun 08, 2016 at 01:57:10PM +0200, Alexander Wirt wrote: > On Wed, 08 Jun 2016, Antonio Terceiro wrote: > > > On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > > > On Wed, 08 Jun 2016, Pirate Praveen wrote: > > > > > > > On Wednesday 08 June 2016 01:07 AM, Bastian Blank wrote: > > > > > [SN: trimmed Cc list, as this is about what Debian wants] > > > > > > > > > > Hi Alex > > > > > > > > > > On Tue, Jun 07, 2016 at 08:06:41PM +0200, Alexander Wirt wrote: > > > > >> Its more things like: > > > > >> - integration into alioth - aka, how easy is it to integrate the already > > > > >> existing identity data (which we want to keep) into the system > > > > > > > > > > This can be easy (use OAUTH2 against the identity provider) or hard > > > > > (convert all data). Also it speaks ldap itself. > > > > > > > > Does alioth/fusionforge already support becoming an OAUTH2 identity > > > > provider? How do other debian services (like nm.debian.org) use alioth > > > > login? [1] I found this [2] > > > I wrote a minimal exporter for user information (no group or acl > > > information) that gets synced to the dacs host. That enables dacs enabled > > > services to use these information. > > > > for authentication, I think you should probably use the Debian SSO with > > client certificates: > > https://wiki.debian.org/DebianSingleSignOn > Nope, thats http only and doesn't cover ssh. gitlab would not need that for ssh pushes; they are done with a "git" user (like in most sane git server infrastructures), and each user uploads their SSH keys via the web interface after logging in against a central authentication provider. > Client certificates also have several problems, see enricos mails for > details about it. sure. > > for authorization, at least if the plan is to mirror the current alioth > > git infra you will need some scripting to sync the alioth data to gitlab > > (I would suggest starting with a very limited pilot with only one of > > very few projects). > I don't think we will give any third party access to the user and > passwordhashes. gitlab wouldn't need password hashes. as long as the central login thingy lets users login to the gitlab web UI, users can set a gitlab-specific password for git push over HTTP(S). then you would just need to know which users are members of which groups so you can create the corresponding structure on gitlab. since anyone can sign up on alioth today and get that, I don't think this will be a problem.
Attachment:
signature.asc
Description: PGP signature