<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"><<a href="mailto:thomas.raehalme@aitiofinland.com" target="_blank">thomas.raehalme@aitiofinland.com</a>></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'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'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, "Bill Burke" <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>> 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>
> What problem does this solve? It seems like an uncommon use case.<br>
><br>
><br>
> Scott Rossillo<br>
> Smartling | Senior Software Engineer<br>
> <a href="mailto:srossillo@smartling.com" target="_blank">srossillo@smartling.com</a> <mailto:<a href="mailto:srossillo@smartling.com" target="_blank">srossillo@smartling.com</a>><br>
><br>
><br>
>> On Dec 2, 2015, at 11:48 AM, Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
>> <mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>> wrote:<br>
>><br>
>> I'm looking into in-memory only no-import federated users. What we<br>
>> would want to do is allow the UserFederationProvider to create an<br>
>> in-memory UserModel and allow for that UserModel to be cached via our<br>
>> current architecture.<br>
>><br>
>> The current design assumes that all federated users are imported. This<br>
>> includes our caching layer too! To add to that, the user isn't cached<br>
>> until the 2nd request i.e.:<br>
>><br>
>> 1. username/password page would hit the UserFederationProvider and the<br>
>> user would be imported into Keycloak. This imported user is not cached,<br>
>> only imported into the database for this request's KeycloakSession<br>
>> 2. OTP Page or code 2 token would then want to lookup the user by id as<br>
>> that is what is stored in the ClientSession. It would hit the keycloak<br>
>> database as it is not cached yet. This lookup loads the cache for the<br>
>> user.<br>
>><br>
>> Getting in-memory zero-import to work is even more tricky. The issue is<br>
>> that ClientSession and UserSession need to lookup clients by id. If the<br>
>> user is not in cache, then the cache needs to lookup the user by id<br>
>> within storage. This lookup also needs to happen if a write operation<br>
>> is performed on a cache user (getDelegateForUpdate()). So, Keycloak<br>
>> needs to know that that ID is not in local storage and must be looked up<br>
>> from a fed provider. The ID must be formed so that the provider fed<br>
>> provider can resolve the lookup. I could use a URI for the ID i.e.<br>
>><br>
>> fed:{providerId}:{login-name}<br>
>><br>
>> The problem with this is that this id would need to be larger than 36<br>
>> characters which is the current column size for UserEntity.id and any<br>
>> other table that references users. I could possibly do:<br>
>><br>
>> fed:{providerAlias}:{login-name}<br>
>><br>
>> But its quite possible that combination would be larger than 36<br>
>> characters. We could also just shrink it to:<br>
>><br>
>> fed:{login-name}<br>
>><br>
>> But then we would have to iterate over every federation provider to find<br>
>> and load the user.<br>
>><br>
>> So in summary:<br>
>> * IDs need to expand from 36 characters to something larger. (255<br>
>> maybe). Don't some DBs have constraints on string primary key size? DB<br>
>> scripts could possibly be<br>
>> * CachedUserProvider and UserFederationManager interfaces would need to<br>
>> be refactored<br>
>> * I don't think UserFederationProvider interface would need to change.<br>
>> But users would have to code for in-memory rather than throwing a switch<br>
>> to just turn it on.<br>
>><br>
>><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>
><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>