[keycloak-dev] PAM integration with FreeIPA

Fri Jun 24 10:36:43 EDT 2016

On 2016-06-24, Stian Thorgersen wrote:
> On 24 June 2016 at 16:08, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > On 2016-06-24, Stian Thorgersen wrote:
> > > On 24 June 2016 at 15:07, Bruno Oliveira <bruno at abstractj.org> wrote:
> > >
> > > > On 2016-06-23, Bill Burke wrote:
> > > > >
> > > > >
> > > > > On 6/23/16 2:56 PM, Bruno Oliveira wrote:
> > > > > > 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.
> > > > > >
> > > > >
> > > > > This is solely to allow keycloak to update passwords?  Not really
> > > > > understanding here.
> > > >
> > > > Not really Bill, to give you more context. Login through PAM is just
> > one
> > > > of the scenarios described by Dmitri at slide #19[1].
> > > >
> > > > * User starts browser and connects to a resource
> > > > * Resource redirects to Keycloak
> > > > * User is presented with a login form
> > > > * User fills username and password
> > > > * User data is collected and passed to SSSD over D-Bus
> > > >
> > > > Here, we can't provide username/password to SSSD, because we don't have
> > > > a DBus interface for it. So instead, we make use of PAM to make it
> > happen.
> > > >
> > >
> > > Isn't the flow actually:
> > >
> > > * User starts browser and connects to a resource
> > > * Resource redirects to Keycloak
> > > * User is presented with a login form
> > > * User fills username and password
> > > * Username and password is verified through PAM (in the future SSSD once
> > > that becomes available) - this should be a custom authenticator
> > > * User profile is retrieved from SSSD over D-Bus - this should be a
> > custom
> > > user federation provider
> >
> > That's correct, I just quoted the original slides for reference
> > and added the notes (maybe was more confuse than helpful).
> >
> > After the retrieval of user's profile from SSSD. Should the data be
> > propagated
> > to Keycloak database? Should we validate such credentials on the next
> > login?
> >
>
> The user profile would currently be imported into Keycloak database as
> that's how user federation currently works. Bill is working on changing
> that though so user profile would not be imported in the future.

It's always better to double check than be sorry :)

>
> Not sure what you mean about validate such credentials - username/password
> would always be verified against PAM

Never mind, you already answered. Thank you.

Will move forward based on our discussion here and for sure ask more questions.

>
>
> >
> > > * Done
> > >
> > >
> > > >
> > > > * SSSD authenticates against AD
> > > > * Authentication complete (against FreeIPA)
> > > >
> > > > This is where I need some help to define what would be the best next
> > > > step for us.
> > > >
> > > > * Assertion/token is issued
> > > > * User is redirected to the resource
> > > >
> > > > In this scenario nothing is stored/updated on Keycloak.
> > > >
> > > > >
> > > > > > 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
> > > > ).
> > > > > >
> > > > >
> > > > > It looks like a conversation requires some sort of session object or
> > > > session
> > > > > connection.  Remember, a web login can span multiple requests and
> > could
> > > > > possibly be serviced on different machines.  Sounds like any
> > integration
> > > > > with PAM is going to be quite limited.  Maybe that's what you are
> > getting
> > > > > at?
> > > >
> > > > I fully understand that, certainly something that requires more testing
> > > > to see how SSSD will behave with PAM.
> > > >
> > > > >
> > > > > Or are you just talking about writing a client adapter and this has
> > > > nothing
> > > > > to do with the Keycloak auth server?
> > > >
> > > > Good question. My initial naive idea was to have an authenticator SPI
> > > > for PAM and benefit from the work already done by Marek with LDAP and
> > > > Kerberos. Plus, have a federation SPI to retrieve user's data from SSSD
> > > > and propagate it to Keycloak.
> > > >
> > > > >
> > > > > Also, where does the identity data come into play (aka LDAP info)?
> > Is
> > > > this
> > > > > also a part of the PAM/SSSD flow?
> > > >
> > > > At the flow described here#17[2]:
> > > >
> > > > * User starts browser and connects to a resource
> > > > * Resource redirects to Keycloak
> > > > * User is presented with a login form
> > > > * User fills username and password
> > > > * User data is collected and passed to SSSD over D-Bus
> > > > * SSSD authenticates against LDAP server
> > > > * Authentication complete
> > > > * Assertion/token is issued
> > > > * User is redirected to the resource
> > > >
> > > > >
> > > > > Bill
> > > >
> > > > [1] -
> > > >
> > https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
> > > > [2] -
> > > >
> > https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107
> > > > --
> > > >
> > > > abstractj
> > > > PGP: 0x84DC9914
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> >

--

abstractj
PGP: 0x84DC9914