thank you, that helped.
got the first round of changes done. some test cases are now failing.
this is due to PasswordPolicy loading the PasswordPolicyProvider
implementations. looks like the KeycloakSessionFactory::init was not
called. factoriesMap is null.
probably due to more setup / config needed. had a look at some of the
provider tests (CustomIdentityProvider) but did not spot anything specific.
do you have any hints?
On 04/29/2016 11:10 AM, Stian Thorgersen wrote:
Pass in PasswordPolicy then. PasswordPolicy can store the config in
the
correct format. getInt(String provider) would parse string and store as
an int in a map.
This can be improved later, we're currently having a separate discussion
about adding something like this. Ideally password policies would also
support more advanced configuration like authenticators, mappers, etc
already do. That on the other side is more work. If you want to do
something like what they do that would be great though.
On 29 April 2016 at 09:48, Roelof Naude <roelof.naude(a)gmail.com
<mailto:roelof.naude@gmail.com>> wrote:
hi,
adding the config to the verify / validate method makes no sense.
take for instance HashIterations. it needs to keep the config for
later when the password encode takes place. PasswordPolicy::validate
is called after construction of the policies...at a time when the
configuration has been parsed already. re-parsing the config for
every validate can be expensive.
PasswordPolicyProvider implementations will most likely not access
external resources. granted, one cannot foresee all future usage
patterns either.
On 04/29/2016 07:58 AM, Stian Thorgersen wrote:
Simplest option is to simply add the config to the verify method.
We have some other SPIs that have more than one instance of a given
provider per-realm, but as you say they're not associated with the
session. This could cause them not to be closed, or to have multiple
instances with same config created per-session.
On 28 April 2016 at 15:37, Roelof Naude <roelof.naude(a)gmail.com
<mailto:roelof.naude@gmail.com>
<mailto:roelof.naude@gmail.com <mailto:roelof.naude@gmail.com>>>
wrote:
thank you. have made some headway with this.
there is a slight issue though. Providers are cached and
thus mostly
stateless.
password policies on the other hand are constructed
on-demand and
may contain configuration. this configuration can be different
between various realms, e.g. HashIterations could be 20 for
realm1
and 200 for realm2.
the current provider loading mechanisms caches both the
factory and
provider instances.
1. is there a session instance per realm? if so, then there
is no issue
2. if not, how do you propose creating policy instances per
realm?
PasswordPolicyFactory could expose an extra method,
create(String
arg), but the provider loading mechanism will ignore it.
one could
add specific knowledge of that method, but that feels wrong.
another option would be to teach KeycloakSession to return a
ProviderFactory instance. PasswordPolicy could call this
method to
create PasswordPolicyProvider instances on-demand. this
method would
delegate to the underlying KeycloakSessonFactory to lookup the
appropriate factory.
this last option could work. would prefer to clear it with
you guys
first though.
On 04/28/2016 07:51 AM, Stian Thorgersen wrote:
First thing would be to create PasswordPolicySPI,
PasswordPolicyProviderFactory
and PasswordPolicyProvider. PasswordPolicyProvider
should have same
methods as Policy. You'd then have to extract all
built-in providers
from PasswordPolicy into PasswordPolicyProvider
implementations,
this
should be relatively straightforward as they are
already "id" ->
implementation, just means you retrieve it with
KeycloakSession
rather
than hard-coded in PasswordPolicy. PasswordPolicy
should then be
change
to use KeycloakSession to retrieve
PasswordPolicyProvider instead of
hard-coded Policy implementations.
Next step would be admin console integration. At the
moment the
list of
policies is hard-coded it would need to get the list of
policies
from
server-info instead. There are other bits that use
server-info
to list
providers already so take a look at that. You would
probably
also need
to add a method to PasswordPolicyProvider to return a
description of the
policy for the admin console tooltips.
On 25 April 2016 at 18:36, Roelof Naude
<roelof.naude(a)gmail.com <mailto:roelof.naude@gmail.com>
<mailto:roelof.naude@gmail.com
<mailto:roelof.naude@gmail.com>>
<mailto:roelof.naude@gmail.com
<mailto:roelof.naude@gmail.com> <mailto:roelof.naude@gmail.com
<mailto:roelof.naude@gmail.com>>>>
wrote:
thank you all for the quick response.
do you guys have a basic idea on how to approach
the policy
spi? we
are more than willing to help out to get it done.
maintaining a fork is maybe an option to resolve the
immediate need,
but would prefer to keep things upstream as much
as possible.
On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen
<sthorger(a)redhat.com <mailto:sthorger@redhat.com>
<mailto:sthorger@redhat.com <mailto:sthorger@redhat.com>>
<mailto:sthorger@redhat.com
<mailto:sthorger@redhat.com> <mailto:sthorger@redhat.com
<mailto:sthorger@redhat.com>>>> wrote:
We an to introduce a password policy spi soon,
but for now
you're stuck with the built-in policies.
On 25 Apr 2016 16:43, "Bruno Oliveira"
<bruno(a)abstractj.org <mailto:bruno@abstractj.org>
<mailto:bruno@abstractj.org <mailto:bruno@abstractj.org>>
<mailto:bruno@abstractj.org
<mailto:bruno@abstractj.org>
<mailto:bruno@abstractj.org
<mailto:bruno@abstractj.org>>>> wrote:
I believe we don't have an SPI for this,
yet. See:
https://issues.jboss.org/browse/KEYCLOAK-2824.
IMO, Argon2 is completely new and aside
from the
bindings,
we don't have
a Java implementation, yet for this. I'm
not sure
if is a
good idea to
introduce C to the codebase, but totally
doable to
have an
SPI for
policies.
On 2016-04-25, Roelof Naude wrote:
> hi,
>
> a client has requested the use of the
argon2 [1, 2]
password hashing
> scheme. this can easily be added as an
external
provider.
we do however
> require custom password policies, e.g.
memory /
parallelism cost as well as
> salt length. AFAIK there is no way to
provide policy
extensions using a
> provider interface?
>
> would argon2 be a worthwhile contribution?
>
> regards
> roelof.
>
> [1]
https://github.com/P-H-C/phc-winner-argon2
> [2]
https://github.com/phxql/argon2-jvm
>
_______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
<mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
<mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
<mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
PGP: 0x84DC9914
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
<mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
<mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
<mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev