<div dir="ltr">Just to check - PAM can have multiple ongoing conversations on the same box right?</div><div class="gmail_extra"><br><div class="gmail_quote">On 24 June 2016 at 16:02, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 24 June 2016 at 16:00, John Dennis <span dir="ltr"><<a href="mailto:jdennis@redhat.com" target="_blank">jdennis@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 06/24/2016 09:52 AM, Stian Thorgersen wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
<br>
On 24 June 2016 at 15:07, Bruno Oliveira <<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a><br></span><div><div>
<mailto:<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>>> wrote:<br>
<br>
On 2016-06-23, Bill Burke wrote:<br>
><br>
><br>
> On 6/23/16 2:56 PM, Bruno Oliveira wrote:<br>
> > On 2016-06-23, Bill Burke wrote:<br>
> > ><br>
> > ><br>
> > > On 6/23/16 12:25 PM, John Dennis wrote:<br>
> > > > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:<br>
> > > > > Good morning,<br>
> > > > ><br>
> > > > > One of the use case scenarios described for FreeIPA, is<br>
the integration via PAM<br>
> > > > > and SSSD, which "automagically" handles the authentication<br>
against the IdM.<br>
> > > > ><br>
> > > > > This first step requires pretty much an IPA setup, but<br>
> > > > > works with libpam4j[1]. Now, thinking about Keycloak, I<br>
> > > > > would like to have an Authenticator for PAM[2], which is<br>
pretty much our<br>
> > > > > UsernamePasswordForm + PAM. Does it make sense?<br>
> > > > ><br>
> > > > > Current flow:<br>
> > > > ><br>
> > > > > * User logs into Web application with username/password<br>
> > > > > * PAM authenticator collects data and authenticate against PAM<br>
> > > > > * SSSD authenticates against IdM<br>
> > > > > * Authentication is complete<br>
> > > > ><br>
> > > > > After the last step, should we propagate that user to our<br>
database?<br>
> > > > > Maybe, like Marek already mentioned, have a<br>
SSSDFederationProvider?<br>
> > > > ><br>
> > > > > [1] -<br>
> > > > ><br>
<a href="http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar" rel="noreferrer" target="_blank">http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar</a><br>
> > > > > [2] -<br>
<a href="https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html" rel="noreferrer" target="_blank">https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html</a><br>
> > > ><br>
> > > > Simo brought up a concern after forwarding this to our<br>
internal identity<br>
> > > > team list. His comment is:<br>
> > > ><br>
> > > > ><br>
> > > > > Current flow:<br>
> > > > ><br>
> > > > > * User logs into Web application with username/password<br>
> > > > > * PAM authenticator collects data and authenticate<br>
against PAM<br>
> > > ><br>
> > > > I am worried about how these 2 steps are expressed, it seem<br>
to imply PAM<br>
> > > > is used only as a username/password verifier.<br>
> > > > There is no mention/awarness of PAM conversations where we<br>
can prompt<br>
> > > > for things like second factors or password changes.<br>
> > > ><br>
> > ><br>
> > > Ok, I've spent maybe 20 seconds googling into what PAM<br>
conversations are<br>
> > > "PAM example conversation code". You'll have to explain to<br>
me why PAM<br>
> > > conversations have any relevance to web login. Just looking<br>
at this<br>
> > > example:<br>
> > ><br>
> > ><br>
<a href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html" rel="noreferrer" target="_blank">https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html</a><br>
> > ><br>
> > > It looks as if PAM conversations are targeted to simple text<br>
logins<br>
> > > (i.e. SSH, telnet, etc.). Pushing and pulling text to and<br>
from stdin<br>
> > > and stdout. What does that have to do with web login?<br>
> ><br>
> > Your question is totally fair. And the reason why we have to<br>
integrate<br>
> > with PAM is pretty much because there's no DBus interface for SSSD<br>
> > to provide username/password. Otherwise we would just communicate<br>
> > directly with DBus and call it a day.<br>
> ><br>
><br>
> This is solely to allow keycloak to update passwords? Not really<br>
> understanding here.<br>
<br>
Not really Bill, to give you more context. Login through PAM is just one<br>
of the scenarios described by Dmitri at slide #19[1].<br>
<br>
* User starts browser and connects to a resource<br>
* Resource redirects to Keycloak<br>
* User is presented with a login form<br>
* User fills username and password<br>
* User data is collected and passed to SSSD over D-Bus<br>
<br>
Here, we can't provide username/password to SSSD, because we don't have<br>
a DBus interface for it. So instead, we make use of PAM to make it<br>
happen.<br>
<br>
<br>
Isn't the flow actually:<br>
<br>
* User starts browser and connects to a resource<br>
* Resource redirects to Keycloak<br>
* User is presented with a login form<br>
* User fills username and password<br>
* Username and password is verified through PAM (in the future SSSD once<br>
that becomes available) - this should be a custom authenticator<br>
* User profile is retrieved from SSSD over D-Bus - this should be a<br>
custom user federation provider<br>
* Done<br>
</div></div></blockquote>
<br>
Yes, this is a good summary Stian and clearly articulates the immediate first implementation.<br>
<br>
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.<br></blockquote><div><br></div></div></div><div>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.</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<br>
<br>
* SSSD authenticates against AD<br>
* Authentication complete (against FreeIPA)<br>
<br>
This is where I need some help to define what would be the best next<br>
step for us.<br>
<br>
* Assertion/token is issued<br>
* User is redirected to the resource<br>
<br>
In this scenario nothing is stored/updated on Keycloak.<br>
<br>
><br>
> > The goal is pretty much to be used for Basic Authentication.<br>
> ><br>
> > ><br>
> > > As for PAM itself, it looks like it is a library. (again a 20 second<br>
> ><br>
> > It's pretty much a low level authentication module to support multiple<br>
> > schemes like: login, ftp, ssh, telnet...(you certainly found it already)<br>
> ><br>
> > > Google search). What I don't know is where PAM ends and SSSD takes<br>
> > > over. So its hard to give you advice.<br>
> ><br>
> > This is how it happens from my understanding:<br>
> ><br>
> > 1. We start the PAM conversation from our client application (a IPA client machine),<br>
> > pam_sss is contacted (SSSD)<br>
> > 2. SSSD's PAM responder receives the authentication request and forwards<br>
> > it to FreeIPA server<br>
> > 3. FreeIPA server process the request and returns the result back to PAM<br>
> > responder.<br>
> ><br>
> > The data flow is better described here (<a href="https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder" rel="noreferrer" target="_blank">https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder</a>).<br>
> ><br>
><br>
> It looks like a conversation requires some sort of session object or session<br>
> connection. Remember, a web login can span multiple requests and could<br>
> possibly be serviced on different machines. Sounds like any integration<br>
> with PAM is going to be quite limited. Maybe that's what you are getting<br>
> at?<br>
<br>
I fully understand that, certainly something that requires more testing<br>
to see how SSSD will behave with PAM.<br>
<br>
><br>
> Or are you just talking about writing a client adapter and this has nothing<br>
> to do with the Keycloak auth server?<br>
<br>
Good question. My initial naive idea was to have an authenticator SPI<br>
for PAM and benefit from the work already done by Marek with LDAP and<br>
Kerberos. Plus, have a federation SPI to retrieve user's data from SSSD<br>
and propagate it to Keycloak.<br>
<br>
><br>
> Also, where does the identity data come into play (aka LDAP info)? Is this<br>
> also a part of the PAM/SSSD flow?<br>
<br>
At the flow described here#17[2]:<br>
<br>
* User starts browser and connects to a resource<br>
* Resource redirects to Keycloak<br>
* User is presented with a login form<br>
* User fills username and password<br>
* User data is collected and passed to SSSD over D-Bus<br>
* SSSD authenticates against LDAP server<br>
* Authentication complete<br>
* Assertion/token is issued<br>
* User is redirected to the resource<br>
<br>
><br>
> Bill<br>
<br>
[1] -<br>
<a href="https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130" rel="noreferrer" target="_blank">https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130</a><br>
[2] -<br>
<a href="https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107" rel="noreferrer" target="_blank">https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107</a><br>
--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<br>
_______________________________________________<br>
keycloak-dev mailing list<br></div></div>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a> <mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><span><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
<br>
</span></blockquote><span><font color="#888888">
<br>
<br>
-- <br>
John<br>
</font></span></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>