<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">IMO the more important use-case that
      in-memory federated users is the caching of federated users.<br>
      <br>
      Currently if you call: session.users().getUserById() and the user
      with ID "123" is LDAP (or other federationProvider) user, there is
      always call to UserFederationProvider.validateAndProxy , which
      results in LDAP query. <br>
      <br>
      If we introduce the chaining of UserProvider (something I already
      proposed earlier), you can switch UserFederationProvider with
      cache, so you will have:<br>
      cache =&gt; userFederationManager =&gt; JPA<br>
      <br>
      instead of current:<br>
      <br>
      userFederationManager =&gt; cache =&gt; JPA<br>
      <br>
      <br>
      With that in mind, we can easily implement in-memory as another
      implementation of UserProvider, which will hold users purely
      in-memory. Our current <span style="background-color:#e4e4ff;">DefaultCacheUserProvider
        always require delegate to call write operations. But this
        in-memory provider would be something different. It won't use
        any delegate as it will be in the end of the chain. So for
        in-memory federation you will just configure:<br>
        <br>
        userFederationManager =&gt; inMemoryProvider<br>
        <br>
        and you're done. No needs for special ID handling or something
        like that.<br>
        <br>
        With chaining of UserProvider we have biggest flexibility for
        various needs IMO. That's why I would rather go this way TBH.<br>
        Marek</span>
      <meta http-equiv="content-type" content="text/html;
        charset=windows-1252">
      <br>
      <br>
      On 02/12/15 17:48, Bill Burke wrote:<br>
    </div>
    <blockquote cite="mid:565F20F9.6050400@redhat.com" type="cite">
      <pre wrap="">I'm looking into in-memory only no-import federated users.  What we 
would want to do is allow the UserFederationProvider to create an 
in-memory UserModel and allow for that UserModel to be cached via our 
current architecture.

The current design assumes that all federated users are imported.  This 
includes our caching layer too!  To add to that, the user isn't cached 
until the 2nd request i.e.:

1. username/password page would hit the UserFederationProvider and the 
user would be imported into Keycloak.  This imported user is not cached, 
only imported into the database for this request's KeycloakSession
2. OTP Page or code 2 token would then want to lookup the user by id as 
that is what is stored in the ClientSession.  It would hit the keycloak 
database as it is not cached yet.  This lookup loads the cache for the user.

Getting in-memory zero-import to work is even more tricky.  The issue is 
that ClientSession and UserSession need to lookup clients by id.  If the 
user is not in cache, then the cache needs to lookup the user by id 
within storage.  This lookup also needs to happen if a write operation 
is performed on a cache user (getDelegateForUpdate()).  So, Keycloak 
needs to know that that ID is not in local storage and must be looked up 
from a fed provider.  The ID must be formed so that the provider fed 
provider can resolve the lookup.  I could use a URI for the ID i.e.

fed:{providerId}:{login-name}

The problem with this is that this id would need to be larger than 36 
characters which is the current column size for UserEntity.id and any 
other table that references users.   I could possibly do:

fed:{providerAlias}:{login-name}

But its quite possible that combination would be larger than 36 
characters.  We could also just shrink it to:

fed:{login-name}

But then we would have to iterate over every federation provider to find 
and load the user.

So in summary:
* IDs need to expand from 36 characters to something larger. (255 
maybe).  Don't some DBs have constraints on string primary key size?  DB 
scripts could possibly be
* CachedUserProvider and UserFederationManager interfaces would need to 
be refactored
* I don't think UserFederationProvider interface would need to change. 
But users would have to code for in-memory rather than throwing a switch 
to just turn it on.



</pre>
    </blockquote>
    <br>
  </body>
</html>