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>> 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>> 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>> 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>
>
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>
https://lists.jboss.org/mailman/listinfo/keycloak-dev