[keycloak-dev] PAM integration with FreeIPA
John Dennis
jdennis at redhat.com
Fri Jun 24 10:00:01 EDT 2016
On 06/24/2016 09:52 AM, Stian Thorgersen wrote:
>
>
> On 24 June 2016 at 15:07, Bruno Oliveira <bruno at abstractj.org
> <mailto: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
Yes, this is a good summary Stian and clearly articulates the immediate
first implementation.
I think the only additional thing is sometime down the road it might not
just be one login form, you might be prompted for additional
information. But that is *not* part of the requirements for the first
implementation as I understand it. Just don't box yourself into a corner
by prohibiting it down the road.
>
>
> * 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 <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
John
More information about the keycloak-dev
mailing list