[keycloak-dev] PAM integration with FreeIPA

[Bill Burke]

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