<div dir="ltr">Sigbjørn,<div><br></div><div>Thank you for your suggestions. They have been extremely helpful. I changed my custom authenticator to extend AbstractIdpAuthenticator and the code I put in the authenticateImpl method to get the behavior I want is almost trivial:</div><div><br></div><div><div><font face="monospace, monospace">    UserModel existingUser = context.getSession().users().getUserByUsername(brokerContext.getModelUsername(), context.getRealm());</font></div><div><font face="monospace, monospace">    if (existingUser != null) {</font></div><div><font face="monospace, monospace">        context.setUser(existingUser);<br></font></div><div><font face="monospace, monospace">        context.success();</font></div><div><font face="monospace, monospace">    } else {</font></div><div><font face="monospace, monospace">        context.failure(AuthenticationFlowError.UNKNOWN_USER);</font></div><div><font face="monospace, monospace">    }</font></div><div><font face="monospace, monospace">  }</font></div></div><div><br></div><div>I suspect there is more I need to do in this method, such as the part you mention about the FederatedIdentityModel. I&#39;m not sure what needs to be done with that. But your suggestions have got me moving in the right direction.</div><div><br></div><div>Thanks again for your help.</div><div><br></div><div>Glenn</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 25, 2016 at 10:18 AM, Sigbjørn Dybdahl <span dir="ltr">&lt;<a href="mailto:sigbjorn@fifty-five.com" target="_blank">sigbjorn@fifty-five.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Glenn,<div><br></div><div>This seems familiar to what I implemented recently with a custom authenticator. That is, upon response from my trusted IdP the authenticate function does the following:</div><div><ol><li>gets the BrokeredIdentityContext from the client session (check out AbstractIdpAuthenticator for an example of how it&#39;s done)</li><li>adding the values in the BrokeredIdentiyContext to the user (by creating a FederatedIdentityModel and adding it to the user)</li><li>setting the user to the AuthenticationFlowContext</li><li>calling success on the AuthenticationFlowContext</li></ol><div>Hopefully this will help you find what&#39;s not working with your implementation.</div></div><div><br></div><div><br></div><div>Sigbjørn<br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 25 August 2016 at 15:12, Glenn Campbell <span dir="ltr">&lt;<a href="mailto:campbellg@teds.com" target="_blank">campbellg@teds.com</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5"><div dir="ltr">I still haven&#39;t gotten anywhere with this. Here&#39;s what I&#39;ve tried so far:<div><br></div><div>1) modifying First Broker Login flow as follows - </div><div>Review Profile - disabled</div><div>Create User If Unique - alternative</div><div>Handle Existing Account - alternative</div><div>everything under Handle Existing Account that can be disabled I have disabled</div><div><br></div><div>Result: I authenticate with the remote SAML server but my local Keycloak server displays an error screen saying &quot;Invalid username or password&quot;.</div><div><br></div><div><br></div><div>2) created a custom authentication flow containing the following - </div><div>Create User If Unique - alternative</div><div>A custom authenticator class with an authenticate method that just calls the success method of the AuthenticationFlowContext.</div><div><br></div><div><div>Result: I authenticate with the remote SAML server but my local Keycloak server displays an error screen saying &quot;Invalid username or password&quot;.</div></div><div><br></div><div><br></div><div>As always, any suggestions would be greatly appreciated.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 23, 2016 at 9:49 AM, Glenn Campbell <span dir="ltr">&lt;<a href="mailto:campbellg@teds.com" target="_blank">campbellg@teds.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I have a SAML IdP that is used only for authentication and a separate database that contains information about the users, including roles. I&#39;ve set up the database in User Federation and the SAML IdP in Identity Providers. <div><br></div><div>The problem I have is that when users log in they are prompted to link to an existing account. This is confusing for them because from their perspective the only account they know about is the one on the SAML IdP.</div><div><br></div><div>Is it possible to configure this Identity Provider to be &quot;trusted&quot; so that the accounts are linked automatically? I started looking into creating a custom authenticator based on the documentation and the custom authenticator in the example code but I don&#39;t see what the necessary steps are to cause the automatic account linking.</div><div><br></div><div>Any suggestions would be greatly appreciated.</div></div>
</blockquote></div><br></div>
</div></div><br></div></div>______________________________<wbr>_________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/keycloak-user</a><br></blockquote></div><br><div><br></div>
</div></div></div>
</blockquote></div><br></div>