[keycloak-dev] PAM integration with FreeIPA
Bruno Oliveira
bruno at abstractj.org
Fri Jun 24 10:30:14 EDT 2016
On 2016-06-24, Stian Thorgersen wrote:
> Just to check - PAM can have multiple ongoing conversations on the same box
> right?
That's correct.
>
> On 24 June 2016 at 16:02, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> >
> >
> > On 24 June 2016 at 16:00, John Dennis <jdennis at redhat.com> wrote:
> >
> >> 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.
> >>
> >
> > We can support authentication over multiple steps as we already do that
> > for OTP. However, the problem will be with regards to the conversation as
> > this would require sticky sessions if clustered to make sure the second
> > step is sent to the same node. Can't PAM verify the two independently?
> > First password, then separately OTP? That would make it much simpler and
> > stateless.
> >
> >
> >>
> >>
> >>>
> >>> * 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
> >>
> >
> >
--
abstractj
PGP: 0x84DC9914
More information about the keycloak-dev
mailing list