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. Client certificates also have several problems, see enricos mails for details about it.
> 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. Alex
signature.asc
Description: PGP signature
