<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">What problem does this solve? It seems like an uncommon use case.<div class=""><br class=""></div><div class=""><br class=""><div apple-content-edited="true" class="">
<div class="">Scott Rossillo</div><div class="">Smartling | Senior Software Engineer</div><div class=""><a href="mailto:srossillo@smartling.com" class="">srossillo@smartling.com</a></div><div class=""><br class=""></div><div class=""><div id="watermark" style="box-sizing: border-box; color: rgb(169, 169, 169); font-family: gesta, Arial, Helvetica, sans-serif; font-size: 14px; line-height: 20px; widows: 1; background-color: rgb(255, 255, 255);" class=""></div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Dec 2, 2015, at 11:48 AM, Bill Burke <<a href="mailto:bburke@redhat.com" class="">bburke@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I'm looking into in-memory only no-import federated users. What we <br class="">would want to do is allow the UserFederationProvider to create an <br class="">in-memory UserModel and allow for that UserModel to be cached via our <br class="">current architecture.<br class=""><br class="">The current design assumes that all federated users are imported. This <br class="">includes our caching layer too! To add to that, the user isn't cached <br class="">until the 2nd request i.e.:<br class=""><br class="">1. username/password page would hit the UserFederationProvider and the <br class="">user would be imported into Keycloak. This imported user is not cached, <br class="">only imported into the database for this request's KeycloakSession<br class="">2. OTP Page or code 2 token would then want to lookup the user by id as <br class="">that is what is stored in the ClientSession. It would hit the keycloak <br class="">database as it is not cached yet. This lookup loads the cache for the user.<br class=""><br class="">Getting in-memory zero-import to work is even more tricky. The issue is <br class="">that ClientSession and UserSession need to lookup clients by id. If the <br class="">user is not in cache, then the cache needs to lookup the user by id <br class="">within storage. This lookup also needs to happen if a write operation <br class="">is performed on a cache user (getDelegateForUpdate()). So, Keycloak <br class="">needs to know that that ID is not in local storage and must be looked up <br class="">from a fed provider. The ID must be formed so that the provider fed <br class="">provider can resolve the lookup. I could use a URI for the ID i.e.<br class=""><br class="">fed:{providerId}:{login-name}<br class=""><br class="">The problem with this is that this id would need to be larger than 36 <br class="">characters which is the current column size for UserEntity.id and any <br class="">other table that references users. I could possibly do:<br class=""><br class="">fed:{providerAlias}:{login-name}<br class=""><br class="">But its quite possible that combination would be larger than 36 <br class="">characters. We could also just shrink it to:<br class=""><br class="">fed:{login-name}<br class=""><br class="">But then we would have to iterate over every federation provider to find <br class="">and load the user.<br class=""><br class="">So in summary:<br class="">* IDs need to expand from 36 characters to something larger. (255 <br class="">maybe). Don't some DBs have constraints on string primary key size? DB <br class="">scripts could possibly be<br class="">* CachedUserProvider and UserFederationManager interfaces would need to <br class="">be refactored<br class="">* I don't think UserFederationProvider interface would need to change. <br class="">But users would have to code for in-memory rather than throwing a switch <br class="">to just turn it on.<br class=""><br class=""><br class=""><br class="">-- <br class="">Bill Burke<br class="">JBoss, a division of Red Hat<br class=""><a href="http://bill.burkecentral.com" class="">http://bill.burkecentral.com</a><br class="">_______________________________________________<br class="">keycloak-dev mailing list<br class="">keycloak-dev@lists.jboss.org<br class="">https://lists.jboss.org/mailman/listinfo/keycloak-dev<br class=""></div></div></blockquote></div><br class=""></div></body></html>