Don'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.

On 6/27/16 2:27 AM, Stian Thorgersen wrote:

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

<mailto: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 <mailto:keycloak-dev@lists.jboss.org>
    https://lists.jboss.org/mailman/listinfo/keycloak-dev