Dear all,
Over the last couple of weeks Xavier and I managed to catch up a couple of time to discuss the current status of FAS3. I would like to summarize a little the output of these discussions.
We can basically, consider 3 types of tasks left.
* Development:
Admin panel Xavier is working on providing an Admin panel to FAS3. This would provide a central place for admin tasks such as blocking an user, deleting an account and so on -> Due by next week
Group membership model Xavier is thinking to rework the membership model for FAS groups. There is currently three levels: user, sponsors and admins while there are groups where sponsors might not be needed or where another level could be useful. -> Optional for 3.0, NOTABLOCKER
Unit-tests FAS3 has currently little tests and needs much more -> Would be good to have for 3.0 but NOTABLOCKER (at least for a staging instance)
2FA 2 Factor Authentication is probably the biggest point remaining to develop. In FAS2, yubikey is integrated into FAS, while gauth isn't. For FAS3 we probably want to integrate both so that users have a place to set and reset their tokens. On the otherside, keeping the yubikey and the gauth servers out of FAS3 also make sense. So we may want to find a way for both to share some information where FAS3 would have read/write permissions while the yubikey/gauth servers would have only read.
* Migration
The idea here is two provide two scripts, a python script that will check the FAS2 DB and report problematic data (for example multiple users having the same IRC nick). Then a SQL script to be used once to convert the FAS2 DB into a FAS3 DB or migrate from the FAS2 DB to a different FAS3 DB (we'll see what is the easiest or makes the most sense).
* Integration
There are still quite a few integrations to do. - Packaging Xavier checked and said that all dependencies are present in RHEL, EPEL or Fedora already. We'll need to double-check and request the epel7 branch where needed. - Ipsilon This should likely be the first one to work on, in order to allow login on our apps in staging. - fedora-python Here the client needs to be ported from FAS2 to FAS3. The API has entirely changed and is not backward compatible but we *may* be able to make the API of the client backward compatible. Xavier already started working on this in the FAS3 branch - All our apps using FAS The idea is to deploy FAS3 in staging so that we can test/fix all our apps using FAS one by one and take our time to do this.
As you can see, most of the development will be done by next week, except for the 2FA aspect which we need to figure out. I have volunteered to work on the migration scripts. Xavier and Patrick will need to coordinate for the Ipsilon integration. Then, we should be ready to push a FAS3 instance to staging.
The idea is that we have FAS3 running in staging by Christmas.
How does this sound? Anyone willing to step in?
Thanks for your attention, Pierre & Xavier
On Thu, Oct 29, 2015 at 04:39:20PM +0100, Pierre-Yves Chibon wrote:
2FA 2 Factor Authentication is probably the biggest point remaining to develop. In FAS2, yubikey is integrated into FAS, while gauth isn't. For FAS3 we probably want to integrate both so that users have a place to set and reset their tokens. On the otherside, keeping the yubikey and the gauth servers out of FAS3 also make sense. So we may want to find a way for both to share some information where FAS3 would have read/write permissions while the yubikey/gauth servers would have only read.
You'll need to think about the model a little here. * Do you want users to be able to login with only a single factor? * Two axises -- users and services. sudo is a current service that requires two factors. * Users could be by group ('sysadmin-main'), user who has registered a second factor, etc. * What factors do you want to make necessary to reset a factor? * Currently if you can login to fas you can change your password * Currently you need to satisfactorily prove your identity to a sysadmin-main member in order to reset your gauth token. * What factors do you need in order to set a factor that is currently null? * What factors do you need in order to disable (different than remove! you need to make sure that this cannot be combined with remove to circumvent the factors needed to reset a factor). * Are some factors "more equal" than others? Some current examples: * challenge question or gpg private key gives access to all. * access to email allows reseting the password * (?) access to password allows resetting the yubikey
mricon could be helpful to talk to about thesse policies.
-Toshio
On Thu, 29 Oct 2015 16:39:20 +0100 Pierre-Yves Chibon pingou@pingoured.fr wrote:
..snip...
The idea is that we have FAS3 running in staging by Christmas.
I think thats a great idea. :) And prod not long after? It would be good to get it landed before anything really ramps up for f24
How does this sound? Anyone willing to step in?
Thanks for your attention, Pierre & Xavier
kevin
infrastructure@lists.fedoraproject.org