[keycloak-dev] rethinking credentials

[Stian Thorgersen]

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> 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
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/08e83a39/attachment.html