<div dir="ltr">IMO this should wait, we have more important things to do right now</div><div class="gmail_extra"><br><div class="gmail_quote">On 2 December 2015 at 17:48, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 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>
<span class="HOEnZb"><font color="#888888"><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">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>
</font></span></blockquote></div><br></div>