On 09/17/2014 05:25 AM, Howard Johnson wrote: > > On 16/09/2014 21:24, Fabian Arrotin wrote: >> Yes, the main blocker on CBS isn't (at the moment) the central >> authentication. Koji supports both kerberos and x509 certificates. The >> IPA/FAS discussion is related but not directly required for the CBS >> effort. That's the reason why , due to the small amount of people >> requiring CBS access $now, it was decided with Thomas to start small, >> with our own internal CA to generate our keys/certs for koji and let >> people start using the CBS platform. In parallel, the FAS/IPA/other >> solution discussion can be held/debated/selected. And we'll always >> have a solution to migrate CBS to the other x509 setup we'll have in >> production. > > Speaking personally, I'm quite an IPA advocate, and have done a bunch of > work customising it for $employer and tying various bits of software > into it as an authn/authz source. However, I'm trying not to push it > too hard (not least because I had a brief chat with Jim, and he said > that there were some issues around using it that'd require potential > functionality development in IPA itself, some of which may not be > trivial). FAS works nicely for Fedora, and the potential for federating > Fedora and CentOS FAS does sound quite appealing. > If IPA can be made to work, then I'm all for it. I'd like something we can use that won't require a ton of custom patching in the future. > Is there somewhere we can start collating requirements for the auth > system? The Trello board, or a wiki page maybe? We could use that to > start making a requirements vs software features matrix to help guide > our descisions. We've not put anything together officially, but we do have a basic list. Auth primarily needs to function for git, koji, http, and local auth (for the projects who require a vm). Further integration like the forums or bugs is a bonus, but not a deal breaker. Users need to be able to maintain their own accounts, to include generating an ssl cert for koji, resetting password, uploading ssh keys, etc. If these steps require intervention from someone on the project, then it fails. SIG leaders should be able to manage their own groups, so we'd need tiered permissioning. Project folks add sig leaders, sig leaders can add sig members etc. Currently the only two auth mechanisms that seem to cover both aspects of this are FAS and IPA. Each seem to have a few drawbacks. KB/Fabian, shall we add a trello card with more formal requirements? Then we can do a head-to-head to see what works. I'm entirely fine with having a shoot-out between them. If Howard wants to take on setting up an IPA instance in a vm, I believe Karsten is working on a FAS test instance. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77