<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 2 December 2015 at 18:37, Thomas Raehalme <span dir="ltr">&lt;<a href="mailto:thomas.raehalme@aitiofinland.com" target="_blank">thomas.raehalme@aitiofinland.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I think it would also help if you could limit which users are imported when synchronizing with LDAP. </p>
<p dir="ltr">If only a small number of enterprise users are going to use the application(s) it doesn&#39;t make sense to synchronize them all (could be tens of thousands in total).</p></blockquote><div>I think you can already do that, just don&#39;t setup the sync and it will pull in users only when they login <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Best regards,<br>
Thomas</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Dec 2, 2015 7:33 PM, &quot;Bill Burke&quot; &lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some are balking at importing every user when doing federation with<br>
backends like ldap even though only minimal import is needed (i.e.<br>
username/providerID).<br>
<br>
On 12/2/2015 12:27 PM, Scott Rossillo wrote:<br>
&gt; What problem does this solve? It seems like an uncommon use case.<br>
&gt;<br>
&gt;<br>
&gt; Scott Rossillo<br>
&gt; Smartling | Senior Software Engineer<br>
&gt; <a href="mailto:srossillo@smartling.com" target="_blank">srossillo@smartling.com</a> &lt;mailto:<a href="mailto:srossillo@smartling.com" target="_blank">srossillo@smartling.com</a>&gt;<br>
&gt;<br>
&gt;<br>
&gt;&gt; On Dec 2, 2015, at 11:48 AM, Bill Burke &lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
&gt;&gt; &lt;mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m looking into in-memory only no-import federated users.  What we<br>
&gt;&gt; would want to do is allow the UserFederationProvider to create an<br>
&gt;&gt; in-memory UserModel and allow for that UserModel to be cached via our<br>
&gt;&gt; current architecture.<br>
&gt;&gt;<br>
&gt;&gt; The current design assumes that all federated users are imported.  This<br>
&gt;&gt; includes our caching layer too!  To add to that, the user isn&#39;t cached<br>
&gt;&gt; until the 2nd request i.e.:<br>
&gt;&gt;<br>
&gt;&gt; 1. username/password page would hit the UserFederationProvider and the<br>
&gt;&gt; user would be imported into Keycloak.  This imported user is not cached,<br>
&gt;&gt; only imported into the database for this request&#39;s KeycloakSession<br>
&gt;&gt; 2. OTP Page or code 2 token would then want to lookup the user by id as<br>
&gt;&gt; that is what is stored in the ClientSession.  It would hit the keycloak<br>
&gt;&gt; database as it is not cached yet.  This lookup loads the cache for the<br>
&gt;&gt; user.<br>
&gt;&gt;<br>
&gt;&gt; Getting in-memory zero-import to work is even more tricky.  The issue is<br>
&gt;&gt; that ClientSession and UserSession need to lookup clients by id.  If the<br>
&gt;&gt; user is not in cache, then the cache needs to lookup the user by id<br>
&gt;&gt; within storage.  This lookup also needs to happen if a write operation<br>
&gt;&gt; is performed on a cache user (getDelegateForUpdate()).  So, Keycloak<br>
&gt;&gt; needs to know that that ID is not in local storage and must be looked up<br>
&gt;&gt; from a fed provider.  The ID must be formed so that the provider fed<br>
&gt;&gt; provider can resolve the lookup.  I could use a URI for the ID i.e.<br>
&gt;&gt;<br>
&gt;&gt; fed:{providerId}:{login-name}<br>
&gt;&gt;<br>
&gt;&gt; The problem with this is that this id would need to be larger than 36<br>
&gt;&gt; characters which is the current column size for UserEntity.id and any<br>
&gt;&gt; other table that references users.   I could possibly do:<br>
&gt;&gt;<br>
&gt;&gt; fed:{providerAlias}:{login-name}<br>
&gt;&gt;<br>
&gt;&gt; But its quite possible that combination would be larger than 36<br>
&gt;&gt; characters.  We could also just shrink it to:<br>
&gt;&gt;<br>
&gt;&gt; fed:{login-name}<br>
&gt;&gt;<br>
&gt;&gt; But then we would have to iterate over every federation provider to find<br>
&gt;&gt; and load the user.<br>
&gt;&gt;<br>
&gt;&gt; So in summary:<br>
&gt;&gt; * IDs need to expand from 36 characters to something larger. (255<br>
&gt;&gt; maybe).  Don&#39;t some DBs have constraints on string primary key size?  DB<br>
&gt;&gt; scripts could possibly be<br>
&gt;&gt; * CachedUserProvider and UserFederationManager interfaces would need to<br>
&gt;&gt; be refactored<br>
&gt;&gt; * I don&#39;t think UserFederationProvider interface would need to change.<br>
&gt;&gt; But users would have to code for in-memory rather than throwing a switch<br>
&gt;&gt; to just turn it on.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Bill Burke<br>
&gt;&gt; JBoss, a division of Red Hat<br>
&gt;&gt; <a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; keycloak-dev mailing list<br>
&gt;&gt; <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
&gt;<br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><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>
</blockquote></div>
</div></div><br>_______________________________________________<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></blockquote></div><br></div></div>