<div dir="ltr">That only works if all users have OTP setup. I don&#39;t think we can rely on that and we&#39;ll have to support both options.</div><div class="gmail_extra"><br><div class="gmail_quote">On 27 June 2016 at 14:24, Bill Burke <span dir="ltr">&lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Don&#39;t think that is an issue either.  We can just write another a different flow for PAM and gather password and OTP on the same page, or the same field like RHT IT does for our login.<span class=""><br>
<br>
On 6/27/16 2:27 AM, Stian Thorgersen wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
My hope was that PAM would support verifying password and OTP as two<br>
completely separate calls without requiring a conversation and state<br>
between them. However, sounds like that&#39;s not possible. If libpam4j<br>
doesn&#39;t even support OTP it makes matters even worse.<br>
<br>
The sooner we can use SSSD rather than PAM for authentication the<br>
better. Or at least do the OTP verification over SSSD.<br>
<br>
On 24 June 2016 at 19:14, Bruno Oliveira &lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a><br></span><div><div class="h5">
&lt;mailto:<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;&gt; wrote:<br>
<br>
    On 2016-06-24, Bill Burke wrote:<br>
    &gt;<br>
    &gt;<br>
    &gt; On 6/24/16 9:53 AM, John Dennis wrote:<br>
    &gt;<br>
    &gt; &gt;<br>
    &gt; &gt; Let me try to clarify a few things.<br>
    &gt; &gt;<br>
    &gt; &gt; PAM is designed as a &quot;conversation&quot;, there are a few analogues<br>
    you could<br>
    &gt; &gt; compare it to:<br>
    &gt; &gt;<br>
    &gt; &gt; * a series of requests/responses<br>
    &gt; &gt;<br>
    &gt; &gt; * challenge/response authentication (e.g. CRAM)<br>
    &gt; &gt;<br>
    &gt; &gt; PAM has something equivalent to a session where state is stored<br>
    during<br>
    &gt; &gt; the &quot;conversation&quot;. When you use PAM you establish a context<br>
    (session)<br>
    &gt; &gt; and iterate. In each iteration the PAM library will ask you for<br>
    &gt; &gt; something and you reply. The iteration stops when the library<br>
    signals<br>
    &gt; &gt; completion.<br>
    &gt; &gt;<br>
    &gt;<br>
    &gt; Will the PAM conversation object be able to be serialized<br>
    in-between web<br>
    &gt; requests? Is it something that can be rebuilt with HTTP session<br>
    information?<br>
    &gt;<br>
    &gt; &gt; For simple password auth the iteration is very short. But<br>
    depending on<br>
    &gt; &gt; how the PAM service is configured you could be prompted for other<br>
    &gt; &gt; things. I suspect with Web forms they way you handle this is via<br>
    &gt; &gt; redirects until such time as the PAM conversation completes.<br>
    &gt; &gt;<br>
    &gt;<br>
    &gt; What do you mean by &quot;prompted&quot;?  Are we going to have to<br>
    screen-scrape this<br>
    &gt; information, or is it a well defined structure?<br>
    &gt;<br>
    &gt; &gt; So my suggestion would be to design this where there is a simple web<br>
    &gt; &gt; form prompting for username/password but allow for the fact you<br>
    may have<br>
    &gt; &gt; to redirect to another page.<br>
    &gt; &gt;<br>
    &gt;<br>
    &gt; As I mentioned early, we already have these generic redirection<br>
    &gt; capabilities.    Login is a &quot;workflow&quot; and you can define nodes in<br>
    this<br>
    &gt; workflow.  The current node in the flow can fail, pass, ignore, or<br>
    challenge<br>
    &gt; an incoming request.<br>
    &gt;<br>
    &gt; &gt;<br>
    &gt; &gt; Does that help?<br>
    &gt; &gt;<br>
    &gt;<br>
    &gt; We&#39;re getting there!  :)  My current thoughts are that PAM integration<br>
    &gt; should be implemented as a Keycloak Authenticator and user profile<br>
    lookup,<br>
    &gt; via SSSD, should be done via a User Federation Provider (the new<br>
    interface).<br>
<br>
    Phew! I think we are on the same page about it.<br>
<br>
    &gt;<br>
    &gt; Bill<br>
<br>
    --<br>
<br>
    abstractj<br>
    PGP: 0x84DC9914<br>
    _______________________________________________<br>
    keycloak-dev mailing list<br></div></div>
    <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>&gt;<br>
    <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
<br>
<br>
</blockquote>
</blockquote></div><br></div>