[keycloak-dev] PAM integration with FreeIPA

Fri Jun 24 09:52:25 EDT 2016

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