10:35 a.m.
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?
9:39 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:12 a.m.
On 2016-08-11, Marek Posolda 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.
+1 that would be fantastic, if possible.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
PGP: 0x84DC9914
3:51 p.m.
On 8/16/16 10:12 AM, Bruno Oliveira wrote:
On 2016-08-11, Marek Posolda 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.
+1 that would be fantastic, if possible.
A data model that can store any arbitrary
key-value pair would require a
join with RDBMs storage. Should we keep something like
UsercredValModel, but just add the ability for attributes? Then model
the API so that it can avoid joins? There's also the issue of data
migration from the old tables to the new. Since this is users we could
be talking about tens of thousands of rows.
Bill
2:31 a.m.
On 16/08/16 22:51, Bill Burke wrote:
On 8/16/16 10:12 AM, Bruno Oliveira wrote:
> On 2016-08-11, Marek Posolda 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.
> +1 that would be fantastic, if possible.
A data model that can store any arbitrary key-value pair would require
a join with RDBMs storage. Should we keep something like
UsercredValModel, but just add the ability for attributes? Then model
the API so that it can avoid joins? There's also the issue of data
migration from the old tables to the new. Since this is users we
could be talking about tens of thousands of rows.
Yep, maybe we can keep the
"old" attributes on the UserCredValModel, so
it's not needed to migrate and most important credential types (
password, OTP) don't need to change anything. Still we can add key-value
for other credential types? Maybe the caching of users and user
credentials also helps with the performance, so the performance
bottleneck of joins won't be so bad (but yes, I know that we need to
limit size of userCache cache, so the same user and his credential may
be still downloaded from underlying DB multiple times...)
Marek
Bill
6:38 a.m.
If we're introducing a new credentials SPI should be consider using it for
realms and clients as well?
Realms currently have a few things, but we soon need to support key
rotation which would mean a realm could have more than one keypair at a time
Clients already have secret or keypair based auth, but will in the future
need certs. Then there's also needs for custom authenticators to store
credentials.
On 23 August 2016 at 09:31, Marek Posolda <mposolda(a)redhat.com> wrote:
On 16/08/16 22:51, Bill Burke wrote:
>
>
> On 8/16/16 10:12 AM, Bruno Oliveira wrote:
>> On 2016-08-11, Marek Posolda 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.
>> +1 that would be fantastic, if possible.
> A data model that can store any arbitrary key-value pair would require
> a join with RDBMs storage. Should we keep something like
> UsercredValModel, but just add the ability for attributes? Then model
> the API so that it can avoid joins? There's also the issue of data
> migration from the old tables to the new. Since this is users we
> could be talking about tens of thousands of rows.
Yep, maybe we can keep the "old" attributes on the UserCredValModel, so
it's not needed to migrate and most important credential types (
password, OTP) don't need to change anything. Still we can add key-value
for other credential types? Maybe the caching of users and user
credentials also helps with the performance, so the performance
bottleneck of joins won't be so bad (but yes, I know that we need to
limit size of userCache cache, so the same user and his credential may
be still downloaded from underlying DB multiple times...)
Marek
>
> Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:43 a.m.
I'm only thinking about users right now. That in itself is a big
complex problem. Clients are users, so how would they be different?
On 8/23/16 7:38 AM, Stian Thorgersen wrote:
If we're introducing a new credentials SPI should be consider
using it
for realms and clients as well?
Realms currently have a few things, but we soon need to support key
rotation which would mean a realm could have more than one keypair at
a time
Clients already have secret or keypair based auth, but will in the
future need certs. Then there's also needs for custom authenticators
to store credentials.
On 23 August 2016 at 09:31, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 16/08/16 22:51, Bill Burke wrote:
>
>
> On 8/16/16 10:12 AM, Bruno Oliveira wrote:
>> On 2016-08-11, Marek Posolda 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.
>> +1 that would be fantastic, if possible.
> A data model that can store any arbitrary key-value pair would
require
> a join with RDBMs storage. Should we keep something like
> UsercredValModel, but just add the ability for attributes? Then
model
> the API so that it can avoid joins? There's also the issue of data
> migration from the old tables to the new. Since this is users we
> could be talking about tens of thousands of rows.
Yep, maybe we can keep the "old" attributes on the
UserCredValModel, so
it's not needed to migrate and most important credential types (
password, OTP) don't need to change anything. Still we can add
key-value
for other credential types? Maybe the caching of users and user
credentials also helps with the performance, so the performance
bottleneck of joins won't be so bad (but yes, I know that we need to
limit size of userCache cache, so the same user and his credential may
be still downloaded from underlying DB multiple times...)
Marek
>
> Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
1:36 a.m.
Clients are not modeled as a user now though. They're linked to a user, but
have a separate mechanism to store credentials right?
On 23 August 2016 at 15:43, Bill Burke <bburke(a)redhat.com> wrote:
I'm only thinking about users right now. That in itself is a big
complex
problem. Clients are users, so how would they be different?
On 8/23/16 7:38 AM, Stian Thorgersen wrote:
If we're introducing a new credentials SPI should be consider using it for
realms and clients as well?
Realms currently have a few things, but we soon need to support key
rotation which would mean a realm could have more than one keypair at a time
Clients already have secret or keypair based auth, but will in the future
need certs. Then there's also needs for custom authenticators to store
credentials.
On 23 August 2016 at 09:31, Marek Posolda <mposolda(a)redhat.com> wrote:
> On 16/08/16 22:51, Bill Burke wrote:
> >
> >
> > On 8/16/16 10:12 AM, Bruno Oliveira wrote:
> >> On 2016-08-11, Marek Posolda 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.
> >> +1 that would be fantastic, if possible.
> > A data model that can store any arbitrary key-value pair would require
> > a join with RDBMs storage. Should we keep something like
> > UsercredValModel, but just add the ability for attributes? Then model
> > the API so that it can avoid joins? There's also the issue of data
> > migration from the old tables to the new. Since this is users we
> > could be talking about tens of thousands of rows.
> Yep, maybe we can keep the "old" attributes on the UserCredValModel, so
> it's not needed to migrate and most important credential types (
> password, OTP) don't need to change anything. Still we can add key-value
> for other credential types? Maybe the caching of users and user
> credentials also helps with the performance, so the performance
> bottleneck of joins won't be so bad (but yes, I know that we need to
> limit size of userCache cache, so the same user and his credential may
> be still downloaded from underlying DB multiple times...)
>
> Marek
> >
> > Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
3:55 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:26 a.m.
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(a)redhat.com
<mailto:mposolda@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
3:57 a.m.
We could also enable caching of creds from LDAP with something like:
* Verify plain text password against LDAP
* If OK store the hashed password in the cache
* Next time around we can check against in-mem only
On 10 August 2016 at 17:35, Bill Burke <bburke(a)redhat.com> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2993
days inactive
3008
days old
10 comments
4 participants
participants (4)
-
Bill Burke -
Bruno Oliveira -
Marek Posolda -
Stian Thorgersen