Infrastructure/fas freeipa

Why is the Fedora Project using a custom built identity system (Fedora Account System, aka FAS) rather than (something like) IPA?

We are getting asked this question very often, so we figured we would write the answer down so that in the future, we can just refer people to this page rather than having to remember everything.

First things first:

• Personally, I really like IPA, I do not have a grudge against it or the teams behind it.
• Whenever this page talks about IPA or FreeIPA, we mean either of them interchangeably: to the best of our knowledge the differences between them don't change any of the reasoning in this page.

Our Requirements

The are a set of features that we are currently missing which would be required for Fedora to consider IPA, among which are:

• User self-registration*

We want users to be able to register their accounts themselves, without any action required from the administrators.

• User self-service password reset*

We want users to be able to reset their password, again without administrator action. We do have fallback to GPG key, SSH key or a security question in case they have lost access to their email address which require admin interaction, but the main case should be self-service.

• Fedora Project Contributor Agreement

We need to be able to allow people to register with reasonable minimal information, but still collect additional information at the moment they want to sign the FPCA, which is required for a lot, but not all, groups the user might want to join.

• Integration with Basset

We have been seeing increasing amounts of spam in the Fedora Infrastructure, so any account system needs to be integrated with our anti-spam service. This consists of two separate parts:

- The data needs to be able to be ingested by Basset so it can use the users information to improve it's spam-score.

- The account system needs to be able to ask for authorization from Basset before creating a user or adding them to certain groups, so that we can prevent more and more spam at the account-system level.

• REST API for user information with backwards compatibility

We have an API that users and systems can use to get public information about another user. There are many contributors with many scripts around that work against this API, so we would need some backwards compatibility.

• API tokens issued by Ipsilon

We are seeing more and more applications that require command line or scripted access to FAS. We will be using Ipsilon to issue scoped OAuth2 tokens (will be in Ipsilon after 1.3.0, but code is in FAS3 already).

• Group requirements

Some of our groups require people to be a member of another group, and this requirement is handled at the account system level. This means that someone could not be sponsored or added to the provenpackagers group without being a member of the packagers group.

• Group sponsors/admin

In Fedora, there is a system in place where every group has three levels of access: member, sponsor and admin.

- A group member only get the specific permissions that group entitles them to.

- A group sponsor can add new members to a group, or sponsor applications from people that requested access.

- A group admin can administer the entire roster of the team: he can add new users, promote members to sponsors and sponsors to admin, and demote users from admin to sponsor, sponsor to member and remove members from the group.

After a user has applied for a group (if a group is open to self-application, otherwise after a sponsor or admin applied for them on their behalf), a sponsor or admin of the group needs to approve the user joining the group. A record of this sponsoring must be kept: who sponsored which person into what group when.

Reasons proposed to switch

• "A better tested and audited system."
• "Easier integration into other infrastructure."
• "Test Red Hat's own products."
• "Support for standard protocols like Kerberos."
• "Support from the community and Red Hat in case of any problems."
• "GNOME is using it, so it's fine for community projects."
• "Less in-house development for core infrastructure in the Fedora Infrastructure.", in other words, it would make us require less development in-house in our already small team, freeing time up for other things.

What is missing in IPA

When we previously have provided this list to the IPA team, their reply was that they would work on a Community Portal, which would be a web application for user self-registration and password reset. We were also told that we can clone the group sponsor/admin system by using multiple IPA groups per group ($group, $group-sponsors and $group-admins) to provide specific delegations. To this moment, we have not yet heard any suggestions as to how we could handle the FPCA or group requirements.

One issue with the community portal is that we're currently at a deadlock with this: until Fedora gives any promises we would be using IPA with the community portal, they don't want to invest time in it, and until they invest time in it we can't make a well-informed decision: we can hardly say by plans only whether it is something that will solve our goals.

Another issue we have with the community portal is that since the IPA team is explicitly not willing to integrate this into IPA itself, it would leave us with not one but two separate web applications for user management, that users will have to change between to change different parts of their account. ("Forgot your password? You can't do to the account system but you need to go to this other website". Yeah, that sounds kind of awkward to me...)

(In GNOME, this is solved by ssh'ing into the account server which then runs a login script which regenerates a new password and sends it to the registered email address. This is not user-friendly, and definitely not suitable for Fedora since we have many contributors that don't use SSH on a daily basis, and as such can't be expected to know how to use it.)

One issue we see with the multiple groups per group method of handling sponsors and admins is that it becomes unwieldy: not only would we need to write scripts to automatically create all three groups and their respective delegations (there's no way we can write a document on this and expect it to go correct every time), but we would also need all group sponsors and admins to know how this whole system works, or write another web application to wrap around IPA for group management.

Our main issue at this moment is that FAS2 is serving our users and is handling our needs perfectly. FAS3, the next iteration of FAS, is pretty much done at this point, and just needs some tweaking and testing before we can start deploying that.

However, if we were to move to IPA, we would need to put in a lot of engineering time from both the IPA team, but also significantly from our team (Fedora Engineering) to make it work in our usecases.

In our opinion, this defeats the entire "Less in-house development" point that we often hear.

Our answers to the arguments proposed

• "A better tested and audited system."

This one we would totally agree with, and would for us be a reason to switch.

• "Easier integration into other infrastructure."

This would be not be an issue: we would not have any of the protocols other than possibly Kerberos (look further down for that), open from the internet to use, and our applications need to use any of the federated login protocols we have available, of which the list would not change whether we use FAS or IPA, because Ipsilon will provide the same set of features with FAS and IPA.

• "Test Red Hat's own products."

Sure, this would be a nice thing in our opinion, however we are not sure we should do this if the product itself is not a fit for our needs. In our opinion, we need to use software to solve the problems we have, and not use software just to use it. This does mean that if the points below get addressed, this would definitely be a reason in our opinion to use IPA; we just mean that we don't think we should need to change our requirements to use it.

• "Support from the community and Red Hat in case of any problems."

This would definitely be a requirement for us to consider IPA, because where FAS is a reasonably small application that the developers in our team can understand and hack on, IPA is a combination of lots of highly complicated pieces of software. So in our opinion it would not be a reason to change directly, since FAS is small enough that we can deal with it on our own, it would be a requirement to even consider IPA.

• "Support for standard protocols like Kerberos."

This would not require switching to IPA: I have an integration written between FAS and the MIT Kerberos Server that I'm considering deploying in a reasonable short time. While it's nice that IPA has Kerberos support built-in, using IPA would not be a requirement to offer it.

• "GNOME is using it, so it's fine for community projects."

We are fully aware of GNOME using it, as puiterwijk was one of the main drivers behind that. However, there are significant differences between GNOME and most community projects, most of which will be discussed in the next section. One major difference is that GNOME does not allow self-registration: users need to request a user from the accounts team, and then they will create the account. The same accounts team is responsible for most of the ACL granting/revoking, so in this case GNOME is less like a community project and more like any enterprise setup.

Alternative

Given the flexibility of the IPA core projects, I have experimented with some additional ways to still use IPA but still allow our usecases. One such experiment that I've even implemented is a system where we use the FAS frontend, but the backend would be all IPA, spoken to via the LDAP interface.

This experiment did turn out reasonably well, and I have an implementation that could be considered reasonably close to proudction-ready, but this did complicate the entire FAS setup considerably, as it replaced the reasonably simple SQL backend we are currently using with a highly complicated LDAP setup.

Also, this experiment again failed the "Less in-house development" goal, since it meant that I had to throw out the entire IPA web interface and still use our in-house developed web frontend.

Conclusion

Given the IPA team has explicitly said they would not implement many of our use cases in the core IPA setup, we would still be left with the need to do a lot of in-house development, and complicate our setup considerably because we do not know the backend system as well as we know the reasonably small FAS application.

So while we would personally like to be able to use IPA, we think that until our usecases are covered by IPA it would only introduce a lot of complications in our current setup, where the small team of administrators will then have to deal with.