<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 24 June 2016 at 15:07, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">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 the integration via PAM<br>
> > > > > and SSSD, which "automagically" handles the authentication 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 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 database?<br>
> > > > > Maybe, like Marek already mentioned, have a SSSDFederationProvider?<br>
> > > > ><br>
> > > > > [1] -<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] - <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 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 against PAM<br>
> > > ><br>
> > > > I am worried about how these 2 steps are expressed, it seem to imply PAM<br>
> > > > is used only as a username/password verifier.<br>
> > > > There is no mention/awarness of PAM conversations where we 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 conversations are<br>
> > > "PAM example conversation code". You'll have to explain to me why PAM<br>
> > > conversations have any relevance to web login. Just looking at this<br>
> > > example:<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 logins<br>
> > > (i.e. SSH, telnet, etc.). Pushing and pulling text to and 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 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>
</div></div>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>
<span class="">* 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>
</span>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 happen.<br></blockquote><div><br></div><div>Isn't the flow actually:</div><div><br></div><div>* User starts browser and connects to a resource<br><span class="">* Resource redirects to Keycloak<br>* User is presented with a login form<br>* User fills username and password</span></div><div><span class="">* Username and password is verified through PAM (in the future SSSD once that becomes available) - this should be a custom authenticator<br>* User profile is retrieved from SSSD over D-Bus - this should be a custom user federation provider</span><br></div><div><span class="">* Done</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
* SSSD authenticates against AD<br>
</span>* 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>
<span class=""><br>
* Assertion/token is issued<br>
* User is redirected to the resource<br>
<br>
</span>In this scenario nothing is stored/updated on Keycloak.<br>
<span class=""><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>
</span>I fully understand that, certainly something that requires more testing<br>
to see how SSSD will behave with PAM.<br>
<span class=""><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>
</span>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>
<span class=""><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>
</span>At the flow described here#17[2]:<br>
<br>
* User starts browser and connects to a resource<br>
<span class="">* 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>
</span>* SSSD authenticates against LDAP server<br>
<span class="">* Authentication complete<br>
* Assertion/token is issued<br>
* User is redirected to the resource<br>
<br>
><br>
</span>> Bill<br>
<br>
[1] - <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] - <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>
<div class=""><div class="h5">_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">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>
</div></div></blockquote></div><br></div></div>