[CentOS-devel] Switching to centralized authentication for centos.org infra (aka FAS vs IPA)

[Xavier Lamien]

Greetings folks,

As the principal FAS upstream, I would like
to help you guys out making - as much as possible - (the right?) move by
having the right information.

First of all, let's start by a short FAS introduction.

FAS has been designed to be community oriented by providing to the
community a way to operate by itself through teams management (i.e group
membership/management).
As a result, our web interface has to be more than just an administrative
interface to manage users & groups like other does.
I recommend to go read more about it at
https://admin.fedoraproject.org/accounts/about
before go further.

While keeping the openness, we also added:
1. A plugin Interface which let you add any new feature
 Plugin we had developed:
 * asterisk (no longer in prod however the plugin still is maintain)
 * yubikey (some of our group requires their members to have a key to
access bound hosts)
 * OTP 2 factor auth (in a branch)

2. A non-standard API (current master) which let registered people and/or
3rd parties (from login mechanism) to read-only from FAS.

Next is, my feedback after reviewed the wiki page and previous msg:

>> project URL

The project is mainly active on github (fedorahosted.org has been set as
backup)
v2: https://github.com/fedora-infra/fas
v3.0:  https://github.com/fedora-infra/fas/tree/FAS_3.0

>> packages available natively in the distro

We do provide rpm's for rhel
(e.g.
http://infrastructure.fedoraproject.org/6Server/x86_64/fas-0.10.0-5.el6.noarch.rpm
)
FAS v3 package will be in distro as it will be no Fedora project specific.


>> multi-master replication

Is this our we can replicate FAS from a master image?
I really didn't get that one. If someone could explain it to me, that would
be great.


>> kerberos support:

Not supported at this time. We do think of it for a v3.xx though.
But it's not in my priority list unless someone is interesting to work on
it.

>> LDAP support:

FAS v2: no.
FAS v3.2: yes however, the LDAP support will be for group and people
management. We will keep the DB as FAS is not about user and group
management only.

>> It's more or less a "Users CMDB" and cron jobs/scripts are
creating/removing/modifying users/groups locally on each managed system.

Naa, we have a fas-client which actually does the job to synchronize
accounts on hosts.
fas-client has been cron'd as the v2 is a non-daemon tools.
We do have a daemon option though that listen to fedmsg and update hosts on
demand. However, we set up a push-mode into Fedora infra.

>> Mainly written to discuss with the fedmsg bus, and so targetting all
Fedora Applications

FAS has not been written to talk to 3rd parties (as stated in introduction).
fedmsg cames few years after FASv2 launch.
fedmsg is for FAS just another notification mechanism.

>> Written for one project

It has been the case for quite a while before I started work on FAS.
For the record, I maintain the RPM Fusion infra and are using FAS there as
well. even though this is related to fedora project, RPM Fusion are not
providing the same level of services and doesn't have the same team
structure (we don't use license agreement feature, nor asterisk's one,
nor bugzilla feature atm).

>> but we are working on a new fas 3 version that will use flask.

Naa.. FAS 3 is a pyramid app.

>> I guess it would be easier for everybody too, as just for today I've
read that FAS3 would be in fact based on IPA so not on the actual FAS
setup

Nope, it will not rely on FreeIPA as FreeIPA doesn't comply with our need
as stated in introduction.
However, we may look at their kerberos and directory server implementation
as a plugin for FAS.

If you have any question which are not answered here, please feel free to
ask.
Also, as Kevin said, the v3 is being writing and will come up with lot of
features so question here are much appreciate ;)

-
Xavier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20141119/96155619/attachment.html>