[keycloak-dev] PAM integration with FreeIPA

[Bruno Oliveira]

That's not how PAM conversations where supposed to work from my
standpoint. From my understanding, a second factor can be an OTP, secret
question or any other thing.

Indeed libpam4j is quite limited and does not include such conversations
as part of this scope. My last resort is to provide the proper bindings
to make this happen, not easy, not stupid simple, but possible.

On 2016-06-28, Stian Thorgersen wrote:
> That only works if all users have OTP setup. I don't think we can rely on
> that and we'll have to support both options.
>
> On 27 June 2016 at 14:24, Bill Burke <bburke at redhat.com> wrote:
>
> > 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
> >>
> >>
> >>

--

abstractj
PGP: 0x84DC9914