[keycloak-dev] rethinking credentials

[Marek Posolda]

Probably yes. So then maybe we can always cache passwords like we do now 
without an option to disable that?

Marek

On 18/08/16 10:55, Stian Thorgersen wrote:
> If someone can do a heapdump are we not screwed anyways? They can for 
> instance get the realm keys and also probably have access to db 
> connection details as well.
>
> On 11 August 2016 at 16:39, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     I wonder if we can have UserCredentialValueModel to be more generic
>     store? Currently it has properties applicable just to password or OTP
>     credentials, but it will be better to have something more generic
>     based
>     on key-value pairs though.
>
>     For caching of credentials, should it be made configurable if
>     credentials are cached or not? Currently the creds from DB are always
>     cached, which can be an issue for someone in theory (For example if
>     someone do heapdump of Java process, he might be able to see the
>     cached
>     credentials).
>
>     Marek
>
>     On 10/08/16 17:35, Bill Burke wrote:
>     > The credential API for users needs to change.  Here are the types of
>     > credentials and how system interacts:
>     >
>     > 1. Creds stored, gathered, and validated by Keycloak OOTB code.
>     >
>     > 2. Creds stored in external store, but gathered and validated by
>     > Keycloak OOTB code.  (i.e. User Storage SPI returns the credentials
>     > directly)
>     >
>     > 3. Creds gathered by built-in Keycloak OOTB code, but stored and
>     > validated externally (i.e. LDAP).
>     >
>     > 4. Creds gathered by custom Authenticators, stored and validated
>     externally.
>     >
>     > 5. Creds gathered by custom authenticators, stored by keycloak,
>     > validated by custom code.
>     >
>     > There's other combinations as well:
>     >
>     > a. Keycloak stored User, custom credential store
>     >
>     > b. User Storage Provider, keycloak stored creds
>     >
>     > c. User Storage Provider, custom credential store
>     >
>     > Credentials that are validated by Keycloak are currently cached
>     along
>     > with the user.  What sucks about this that some credential types
>     require
>     > a database update, i.e. HOTP which needs to update a counter. 
>     So HOTP
>     > invalidates the user cache every single login. We also want to allow
>     > custom credential stores to be able to cache themselves along
>     with the user.
>     >
>     > What's interesting about #4 is that there really doesn't need to
>     be any
>     > special SPI.  The custom authenticator can lookup the factory and
>     > typecast it to any interface it wants to to validate the credential.
>     > Since our caching layer is a local-only (invalidation cache),
>     cachable
>     > custom externally stored credentials just need a simple.
>     >
>     > Given all this, gonna put some iterations in on a new credential
>     API.
>     > Any other thoughts?
>     >
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/827492dd/attachment-0001.html