[keycloak-dev] PAM integration with FreeIPA

Bruno Oliveira bruno at abstractj.org
Thu Jun 23 14:56:58 EDT 2016


On 2016-06-23, Bill Burke wrote:
>
>
> On 6/23/16 12:25 PM, John Dennis wrote:
> > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
> >> Good morning,
> >>
> >> One of the use case scenarios described for FreeIPA, is the integration via PAM
> >> and SSSD, which "automagically" handles the authentication against the IdM.
> >>
> >> This first step requires pretty much an IPA setup, but
> >> works with libpam4j[1]. Now, thinking about Keycloak, I
> >> would like to have an Authenticator for PAM[2], which is pretty much our
> >> UsernamePasswordForm + PAM. Does it make sense?
> >>
> >> Current flow:
> >>
> >> * User logs into Web application with username/password
> >> * PAM authenticator collects data and authenticate against PAM
> >> * SSSD authenticates against IdM
> >> * Authentication is complete
> >>
> >> After the last step, should we propagate that user to our database?
> >> Maybe, like Marek already mentioned, have a SSSDFederationProvider?
> >>
> >> [1] -
> >> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> >> [2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
> >
> > Simo brought up a concern after forwarding this to our internal identity
> > team list. His comment is:
> >
> >  >
> >  > Current flow:
> >  >
> >  > * User logs into Web application with username/password
> >  > * PAM authenticator collects data and authenticate against PAM
> >
> > I am worried about how these 2 steps are expressed, it seem to imply PAM
> > is used only as a username/password verifier.
> > There is no mention/awarness of PAM conversations where we can prompt
> > for things like second factors or password changes.
> >
>
> Ok, I've spent maybe 20 seconds googling into what PAM conversations are
> "PAM example conversation code".   You'll have to explain to me why PAM
> conversations have any relevance to web login.  Just looking at this
> example:
>
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
>
> It looks as if PAM conversations are targeted to simple text logins
> (i.e. SSH, telnet, etc.).  Pushing and pulling text to and from stdin
> and stdout.  What does that have to do with web login?

Your question is totally fair. And the reason why we have to integrate
with PAM is pretty much because there's no DBus interface for SSSD
to provide username/password. Otherwise we would just communicate
directly with DBus and call it a day.

The goal is pretty much to be used for Basic Authentication.

>
> As for PAM itself, it looks like it is a library.  (again a 20 second

It's pretty much a low level authentication module to support multiple
schemes like: login, ftp, ssh, telnet...(you certainly found it already)

> Google search).  What I don't know is where PAM ends and SSSD takes
> over.  So its hard to give you advice.

This is how it happens from my understanding:

1. We start the PAM conversation from our client application (a IPA client machine),
pam_sss is contacted (SSSD)
2. SSSD's PAM responder receives the authentication request and forwards
it to FreeIPA server
3. FreeIPA server process the request and returns the result back to PAM
responder.

The data flow is better described here (https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder).

>
> Our SPIs can handle challenge response protocols.  Kerberos is an
> example of this in action.  We have 3 SPIs around this right now:
>
> *  Our Authentication SPI is the "authentication conversation" layer
> that is responsible for gathering information and rendering through web
> protocols.  It is a simple workflow engine.
> * Our User Federation SPI is really a storage SPI.  This is used to
> lookup information about a user.  Validation of specific credentials can
> also be delegated to this layer.  Alternatively this layer can queried
> by the Authentication SPI to obtain the user's credentials directly so
> that they can be validated in authentication code.
> * Our Required Actions SPI is similar to authentication SPI in that it
> is a "web conversation".  Required actions are actions an authenticated
> user is required to execute before they can complete web login.
> Examples of this are update password, verify email, setup OTP, terms and
> conditions, etc...
>
> So, there it is.  If you can explain to me the basics I can maybe help
> guide how you should implement this in Keycloak.

Just let me know if what I said makes some sense.

>
> Bill
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914


More information about the keycloak-dev mailing list