I'm not sure what is the policy in Red Hat about that and how difficult it will be to include RH SSO. I assume it needs just new OIDC credentials created on Red Hat side.

This means Red Hatters could use their RH accounts directly, without a FAS login?

Would they need to create a Fedora account separately first? If not, how would we deal with the namespace thing?

I don't think we want to do this. Unless I misunderstand what you are asking for.

Problems off the top of my head:

• We use OIDC / openid on our apps. It would require setup of each one with some redhat.com auth provider, and I don't know if they even expose/use OIDC.
• Someone could have a redhat.com account and not a fedora one, then leave redhat and then... we have no idea who they are or where
• Why does Red Hat get special treatment here? Do we add any provider that asks?

So, off hand, I dont see this as being too workable.

• We use OIDC / openid on our apps. It would require setup of each one with some redhat.com auth provider, and I don't know if they even expose/use OIDC.

I might be naive, but don't we have Fedora SSO? That would be change only on one place.

• Someone could have a redhat.com account and not a fedora one, then leave redhat and then... we have no idea who they are or where

My idea was manually created Fedora account, which can be somehow bind to RH SSO.

• Why does Red Hat get special treatment here? Do we add any provider that asks?

I guess you are asking the former mainly in the context of the latter. But making live easier to substantial number of contributors could justify such exception.

It might be what you are looking for here is cross domain trust between FEDORAPROJECT.ORG and REDHAT.COM domains?
but IPA doesn't support that that I can see and even if it did, we would definitely hit namespace problems... ie, kevin@FEDORAPROJECT.ORG isn't the same as kevin@REDHAT.COM and vice versa. Some people might have the same login in each domain, but not be the same person.

Anyhow, I don't see how we can implement this currently...

but thanks for the idea!

@abbra is this something IPA would consider improving?

(still on vacation this week).

@vondruch I am not sure what you are asking for here. This is an organization policy rather than implementation thing. Fedora Project and Red Hat IT would need to agree on whether they'd trust accounts from each organization and how to handle impersonation by the accounts with the same names, as @kevin noted. Once that is solved, we can talk about trust between two Kerberos realms or mapping of identities, if needed.

I understood It might be what you are looking for here is cross domain trust between FEDORAPROJECT.ORG and REDHAT.COM domains? but IPA doesn't support that that I can see that there is some missing functionality in IPA. Or are the "policy" and "mapping of identities" the only missing bits?

We are working on IPA side to support IPA-IPA trust. See my current report about it: https://vda.li/en/posts/2024/05/31/ipa-ipa-trust-progress/

However, what is asked here does not require full IPA-IPA trust. Red Hat IT already uses Kerberos trust between old Kerberos environment and internal IPA deployment, as outlined in Dustin's talk at FOSDEM 2018. That can be enabled but it is really a question of the organizations agreeing to trust each other, not a technical problem.

In short, using this (closed) ticket to track a technical implementation is wrong, in my opinion. It really first needs a common agreement between two organizations.

@abbra thx a lot for the insights.

@mattdm since you have commented here, any thought on this from the organization POV? Would you be the right person to talk to RH IT? 😇

In my opinion, what could Fedora Infrastructure provide is a way to allow federating to a set of known external IdPs for OIDC authorization if user accounts refer those external sources. In this case Fedora does not need to trust Red Hat IT's environment directly on Kerberos level.

IPA already supports this for Kerberos (called 'external IdP authentication' in FreeIPA). However, it requires support for device authorization grant flow from the IdP. Red Hat's SSO implementation supports it and it is enabled on redhat.com. However, Fedora Infrastructure itself uses Ipsilon IdP and it does not provide device authorization grant flow support at all.

Ipsilon IdP internally uses PAM-based authentication against Fedora Infrastructure's IPA deployment. It is not enabled to handle more than password or OTP-based authentication through that mechanism, mostly because nobody added it. Both password and OTP-based authentication threated the same way: a single credential is passed to PAM exchange and a result is expected to be either success or failure. In case of IdP exchange there is more than one back and forth communication, so it is not possible to use Ipsilon IdP for that, at least now.

It means we cannot enable, for example, @abbra or @vondruch accounts to authenticate against Red Hat SSO in the workflows that involve OAuth2/OIDC/SAML (majority of Fedora apps). We can only enable it for Kerberos authentication and it will behave similar to how we authenticate with OTP tokens right now. In this case Fedora account @abbra would be backed by Red Hat's authorization source over OAuth2 device authorization grant flow and how Red Hat's authenticates the user who is mapped as @abbra on the Fedora side is up to Red Hat. This is an implicit identity mapping, basically: user abbra@FEDORAPROJECT.ORG would be mapped to an account on Red Hat's side but Fedora infrastructure's IPA does its own authority over 'abbra' POSIX account and details.