Just to check - PAM can have multiple ongoing conversations on the
same box
right?
On 24 June 2016 at 16:02, Stian Thorgersen <sthorger(a)redhat.com> wrote:
>
>
> On 24 June 2016 at 16:00, John Dennis <jdennis(a)redhat.com> wrote:
>
>> On 06/24/2016 09:52 AM, Stian Thorgersen wrote:
>>
>>>
>>>
>>> On 24 June 2016 at 15:07, Bruno Oliveira <bruno(a)abstractj.org
>>> <mailto:bruno@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...
>>> > > > > > [2] -
>>>
>>>
https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-s...
>>> > > > >
>>> > > > > 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....
>>> > > >
>>> > > > 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.DataFlowPAMResp...
>>> ).
>>> > >
>>> >
>>> > 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-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sA...
>>> [2] -
>>>
>>>
https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sA...
>>> --
>>>
>>> abstractj
>>> PGP: 0x84DC9914
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>
>> --
>> John
>>
>
>