This is GOA part of an effort to integrate web-based authentication methods into RHEL IdM.

Please see https://vda.li/en/posts/2022/10/28/FreeIPA-Authentication-Improvements-and-Fedora-Infra/ and https://vda.li/en/posts/2022/10/28/FreeIPA-Authentication-Improvements-and-Fedora-Infra-2/ for a larger context.

RHEL 8.7 and 9.1, and Fedora 36+ added support for external IdP authentication in FreeIPA and SSSD. This feature allows to login to RHEL and Fedora systems enrolled into RHEL IdM (FreeIPA) with the help of an externally managed identity provider (IdP) which supports OAuth 2.0 device authorization grant flow as defined in RFC 8628, https://datatracker.ietf.org/doc/rfc8628/. Technically, IdP is asked to authorize access to user information to FreeIPA domain-wide OAuth2 client but since the user needs first to login to the IdP and the workflow is also used within authentication flow in Kerberos pre-authentication in FreeIPA, we call it 'authentication' process.

More details about FreeIPA part and integration through a Kerberos module provided by SSSD can be found in upstream design documents:

• overall design: https://freeipa.readthedocs.io/en/latest/designs/external-idp/external-idp.html
• IPA API details: https://freeipa.readthedocs.io/en/latest/designs/external-idp/idp-api.html
• workshop chapter which shows how it all can be set up and used with Keycloak: https://freeipa.readthedocs.io/en/latest/workshop/12-external-idp-support.html

Since GOA is performing a Kerberos client duties to request initial Kerberos tickets, it needs to support idp pre-authentication mechanism.

The flow roughly goes like this:
-[A] obtain a credential to use as a FAST channel wrapping first, similar to existing 'otp' pre-authentication method
-[B] request a TGT using FAST channel
-[C] if pre-authentication method with ID 150 (idp) is available, the TGT request will advertise it to the KDC and if the user principal has external IdP associated, KDC would respond with 'idp' pre-authentication method response which will contain a prompt message
-[D] GOA needs to show the prompt message and ask a user to go to the site specified in the message
-[E] A user needs to come back to the prompt and confirm the access was granted on the IdP side
-[F] At this point Kerberos client would need to send back its TGT request again

The steps [D]-[E] can be presented in a better way in a graphical environment but please look at the private discussion in the GDM bug 2122076 about Kerberos protocol pecularities.

Step [C] requires GOA to register a prompt callback to intercept the message and display it in UI. This is only possible with raw krb5 calls, no GSS-API, sadly. Please consult SSSD source code if you need a help here (we are happy to help).