On Пан, 24 чэр 2024, Vitaly Zaitsev via devel wrote:
On 24/06/2024 10:45, Alexander Bokovoy wrote:
Can you point me to a discussion where it says it is impossible to
implement that in GOA?
FAS (kinit) should request the OTP code in a separate prompt.
This is not how it works in Kerberos. FAS wrapper (fkinit) is handling
separate prompts but for kinit itself the question asked by the plugin
is only expecting a single answer because the Kerberos client plugin
(otp, in this case) only relays the questions asked by the backend (KDC
part of 'otp' plugin) and there it is a single question. Communication
protocol wise that single answer is treated as a plain text answer which
is passed to a RADIUS server as a part of the Accept-Request request.
This is pretty much generic and cannot be modified. The RADIUS server
backend that FreeIPA provides does a bit of smart logic to split
password and OTP token value in one of use cases internally but this is
not visible to the KDC at all.
If kinit asks for a password and OTP codes in separate prompts, GOA
will be able to parse it, store the password, and ask the user to
enter the OTP code.
No, this will not work at all. The OTP pre-authentication method is not
visible to a Kerberos client unless the client is using a special
Kerberos extension which allows to securely pass the plain text answers
(FAST channel). Without FAST channel established, GOA will not see
anything but password-based and smartcard-based exchanges. So splitting
prompts does not help.
Once GOA is able to create a FAST channel, then prompts will appear and
will be usable in GOA, for all passwordless methods that FreeIPA
provides (RADIUS proxy, otp, FIDO2, and external IdP (OAuth2)). And then
GOA frontend can detect which plugin asks what with those prompts and
add additional logic, like showing prompts differently or combining
password and OTP value entered separately.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
