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.

The sooner we can use SSSD rather than PAM for authentication the better. Or at least do the OTP verification over SSSD.

On 24 June 2016 at 19:14, Bruno Oliveira <bruno@abstractj.org> wrote:
On 2016-06-24, Bill Burke wrote:
>
>
> On 6/24/16 9:53 AM, John Dennis wrote:
>
> >
> > Let me try to clarify a few things.
> >
> > PAM is designed as a "conversation", there are a few analogues you could
> > compare it to:
> >
> > * a series of requests/responses
> >
> > * challenge/response authentication (e.g. CRAM)
> >
> > PAM has something equivalent to a session where state is stored during
> > the "conversation". When you use PAM you establish a context (session)
> > and iterate. In each iteration the PAM library will ask you for
> > something and you reply. The iteration stops when the library signals
> > completion.
> >
>
> Will the PAM conversation object be able to be serialized in-between web
> requests? Is it something that can be rebuilt with HTTP session information?
>
> > For simple password auth the iteration is very short. But depending on
> > how the PAM service is configured you could be prompted for other
> > things. I suspect with Web forms they way you handle this is via
> > redirects until such time as the PAM conversation completes.
> >
>
> What do you mean by "prompted"?  Are we going to have to screen-scrape this
> information, or is it a well defined structure?
>
> > So my suggestion would be to design this where there is a simple web
> > form prompting for username/password but allow for the fact you may have
> > to redirect to another page.
> >
>
> As I mentioned early, we already have these generic redirection
> capabilities.    Login is a "workflow" and you can define nodes in this
> workflow.  The current node in the flow can fail, pass, ignore, or challenge
> an incoming request.
>
> >
> > Does that help?
> >
>
> We're getting there!  :)  My current thoughts are that PAM integration
> should be implemented as a Keycloak Authenticator and user profile lookup,
> via SSSD, should be done via a User Federation Provider (the new interface).

Phew! I think we are on the same page about it.

>
> Bill

--

abstractj
PGP: 0x84DC9914
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev