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