[keycloak-dev] PAM integration with FreeIPA
Stian Thorgersen
sthorger at redhat.com
Fri Jun 24 10:08:32 EDT 2016
Just to check - PAM can have multiple ongoing conversations on the same box
right?
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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/274f7d63/attachment-0001.html
More information about the keycloak-dev
mailing list