[keycloak-dev] PAM integration with FreeIPA

[Stian Thorgersen]

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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160628/d3dfaf45/attachment-0001.html