<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/02/21 7:22 am, Artem Goncharov
wrote:<br class="">
<br>
</div>
<blockquote type="cite"
cite="mid:E335D5E8-8D82-41E8-940B-D8D4142FBEA7@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Hi<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 2. Feb 2021, at 01:43, Adrian Turjak <<a
href="mailto:adriant@catalystcloud.nz" class=""
moz-do-not-send="true">adriant@catalystcloud.nz</a>>
wrote:</div>
<br class="">
<div class="">
<div class="">The biggest issue, and why this area never got
much testing, is because it is effectively useless since
you'd have to supply your MFA values EVERY command.
Imagine how awful that would be for TOTP. The whole point
of the MFA process in keystone with auth-receipt was a
dynamic interactive login. Supplying the MFA upfront isn't
that useful.<br class="">
<br class="">
What the OSC really needs is a `login` command, that goes
through a login process using the auth-receipts workflow
from keystone (asks for password/totp) and sets some sort
of state file. We can't set the environment variables of
the parent shell process, so we'd have to go with a
state/session file. But to avoid it clashing with other
state files and terminal sessions we'd need some way to
tag them by the parent process ID so you can login to more
than one cloud/project/user/etc across multiple terminals.<br
class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I guess we can do something about that. Recently Monty
started and I took over the patch for adding token caching in
the keyring[1]. As such it will not really help, but together
with [2] and [3] we can use authorisation caching on the OSC
side. I was never really giving priority to this, since in a
regular use case it perhaps saves .5 - 1 second, what is not
really noticeable (most time is wasted on initialization).
However in this context it might become really handy. Feel
free to trigger discussion if that looks important.</div>
<div><br class="">
</div>
<div>And yes, I totally agree on the fact, that TOTP/MFA for
scripting is a total disaster, therefore nobody really uses
it.</div>
</div>
</blockquote>
I definitely do think it is important, but then again so would
getting MFA working in Horizon which I was planning to do, but
circumstances beyond my control stopped me from doing that, and I
didn't work on finding someone else to implement it.<br>
<br>
If we did get it working on the CLI, then there might be more push
to get it working on Horizon as well. How auth-receipts and MFA work
is documented fairly well from memory, and we have a very clear
error thrown that lets you build an interactive workflow for asking
for the missing pieces of auth:<br>
<a class="moz-txt-link-freetext" href="https://docs.openstack.org/keystoneauth/latest/authentication-plugins.html#multi-factor-with-v3-identity-plugins">https://docs.openstack.org/keystoneauth/latest/authentication-plugins.html#multi-factor-with-v3-identity-plugins</a><br>
<br>
I can't find the time to implement anything here right now because
of so much internal work, but anything related to MFA feel free to
ping me or just outright add me as reviewer!<br>
<br>
<br>
</body>
</html>