Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2141222

Summary:	[RFE] support idp Kerberos pre-authentication method in FreeIPA environments
Product:	Red Hat Enterprise Linux 9	Reporter:	Alexander Bokovoy <abokovoy>
Component:	gnome-online-accounts	Assignee:	Milan Crha <mcrha>
Status:	CLOSED MIGRATED	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	9.1	CC:	debarshir, pbrezina, sbose, tpopela
Target Milestone:	rc	Keywords:	FutureFeature, MigratedToJIRA
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-09-15 19:34:11 UTC	Type:	Story
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexander Bokovoy 2022-11-09 07:43:33 UTC

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).

Comment 4 Milan Crha 2022-11-09 11:40:06 UTC

Thanks for a bug report. I'm sorry to confess this, but I do not understand a single bit between [A] ... [F]  in the description, I've no idea of krb5, neither GOA, I only do packaging stuff here. Additionally, the thing feels quite complex to be included only in RHEL as a custom patch, it would be a nightmare to maintain. Hence I propose: upstream first.

If Debarshi sent you to fill a bug, I guess he meant an upstream bug, not a RHEL bug. It doesn't make much sense to me otherwise. He's well aware of the situation around GOA, both upstream and downstream. Being that meant as kind of a push on anyone by Debarshi, then, well, whatever.

Comment 5 Milan Crha 2022-11-09 12:15:54 UTC

By the way, GOA checks kerberos tickets roughly every 5 seconds. Does it mean, when the ticket will expire and the re-auth will fail for whatever reason, the user will receive a pre-authentication prompt out of blue? The GOA accounts can be set as "requires user attention", or how it's called, which is indicated in the Settings->Online Accounts, but it's not seen anywhere else, as far as I know (even I do not know much).

Comment 6 Alexander Bokovoy 2022-11-09 12:32:18 UTC

Milan, the purpose of filing this bug was exactly to enable your teams to initiate upstream work. We typically start with RHEL-bound bugs and then open upstream bugs based on those. The bug opened against GDM is to show demand on RHEL, this one is the same.

You may want to copy these details to upstream as needed.

Regarding your other question about five seconds intervals, these are pretty bad practices in general. I understand that GOA had to do that due to lack of notify mechanism for non-filesystem-based ccaches, but even there one would probably be better relying on the ticket lifetime and reverting to more active checks in case tickets disappearing from the credential cache collections underneath. Ticket life time is typically measured in hours, not seconds.

A pre-authetnication prompt out of blue may only appear when a ticket renewal is not possible and the whole process has to start from scratch by asking for a new TGT. I'd say this also should not be done immediately when the ticket expired but rather coordinated with some GNOME applications which ask for a use of a ticket through some higher level API. Ticket renewal in Kerberos is different from re-acquiring an initial ticket granting ticket (TGT), these are two separate processes. Ticket renewal is not requiring any interaction with the user and will not cause asking for any additional information.

Comment 7 Milan Crha 2022-11-09 12:50:27 UTC

Thanks for the clarification. I moved this upstream [1], with slightly modified description, but I'd not have any hope anyway. I had much simpler things there (a two liner) and it was waiting for years until I did the change myself.

[1] https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/231

Comment 8 Tomas Popela 2022-11-09 12:54:18 UTC

(In reply to Alexander Bokovoy from comment #6)
> Milan, the purpose of filing this bug was exactly to enable your teams to
> initiate upstream work. We typically start with RHEL-bound bugs and then
> open upstream bugs based on those.

This whole thing should start in JIRA and the bug should be only used when we will be delivering bits into RHEL.

> The bug opened against GDM is to show demand on RHEL, this one is the same.

Alexander, can you please point me to the GDM bug? The one that you're talking about in the first comment is reported against the ipa component.

Comment 9 Alexander Bokovoy 2022-11-09 12:57:11 UTC

That is the bug I am talking about. We can move it to GDM component because most of work would be done there and in SSSD, not IPA.

Comment 10 Debarshi Ray 2022-11-10 13:35:20 UTC

(In reply to Alexander Bokovoy from comment #6)
> 
> Regarding your other question about five seconds intervals, these are pretty
> bad practices in general. I understand that GOA had to do that due to lack
> of notify mechanism for non-filesystem-based ccaches, but even there one
> would probably be better relying on the ticket lifetime and reverting to
> more active checks in case tickets disappearing from the credential cache
> collections underneath. Ticket life time is typically measured in hours, not
> seconds.

The polling or the need for notification is to monitor changes made 'out of band' through kinit, kdestroy, etc..  GOA will also try to renew tickets added through kinit whenever needed and possible, so it needs to know if a new ticket showed up or got removed.

The polling or the need for notification is not done for checking the renewal or expiry times and responding.  Those are done using alarms that generally fire once in several hours or so.

Comment 12 RHEL Program Management 2023-09-15 19:33:51 UTC

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 13 RHEL Program Management 2023-09-15 19:34:11 UTC

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.