<div dir="ltr">Simplest option is to simply add the config to the verify method. <div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 April 2016 at 15:37, Roelof Naude <span dir="ltr"><<a href="mailto:roelof.naude@gmail.com" target="_blank">roelof.naude@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">thank you. have made some headway with this.<br>
<br>
there is a slight issue though. Providers are cached and thus mostly stateless.<br>
<br>
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.<br>
<br>
the current provider loading mechanisms caches both the factory and provider instances.<br>
<br>
1. is there a session instance per realm? if so, then there is no issue<br>
2. if not, how do you propose creating policy instances per realm?<br>
<br>
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.<br>
<br>
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.<br>
<br>
this last option could work. would prefer to clear it with you guys first though.<span class=""><br>
<br>
On 04/28/2016 07:51 AM, Stian Thorgersen wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
First thing would be to create PasswordPolicySPI,<br>
PasswordPolicyProviderFactory<br>
and PasswordPolicyProvider. PasswordPolicyProvider should have same<br>
methods as Policy. You'd then have to extract all built-in providers<br>
from PasswordPolicy into PasswordPolicyProvider implementations, this<br>
should be relatively straightforward as they are already "id" -><br>
implementation, just means you retrieve it with KeycloakSession rather<br>
than hard-coded in PasswordPolicy. PasswordPolicy should then be change<br>
to use KeycloakSession to retrieve PasswordPolicyProvider instead of<br>
hard-coded Policy implementations.<br>
<br>
Next step would be admin console integration. At the moment the list of<br>
policies is hard-coded it would need to get the list of policies from<br>
server-info instead. There are other bits that use server-info to list<br>
providers already so take a look at that. You would probably also need<br>
to add a method to PasswordPolicyProvider to return a description of the<br>
policy for the admin console tooltips.<br>
<br>
On 25 April 2016 at 18:36, Roelof Naude <<a href="mailto:roelof.naude@gmail.com" target="_blank">roelof.naude@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:roelof.naude@gmail.com" target="_blank">roelof.naude@gmail.com</a>>> wrote:<br>
<br>
thank you all for the quick response.<br>
<br>
do you guys have a basic idea on how to approach the policy spi? we<br>
are more than willing to help out to get it done.<br>
<br>
maintaining a fork is maybe an option to resolve the immediate need,<br>
but would prefer to keep things upstream as much as possible.<br>
<br>
On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen<br></span><span class="">
<<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a> <mailto:<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>>> wrote:<br>
<br>
We an to introduce a password policy spi soon, but for now<br>
you're stuck with the built-in policies.<br>
<br>
On 25 Apr 2016 16:43, "Bruno Oliveira" <<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a><br></span><div><div class="h5">
<mailto:<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>>> wrote:<br>
<br>
I believe we don't have an SPI for this, yet. See:<br>
<a href="https://issues.jboss.org/browse/KEYCLOAK-2824" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-2824</a>.<br>
<br>
IMO, Argon2 is completely new and aside from the bindings,<br>
we don't have<br>
a Java implementation, yet for this. I'm not sure if is a<br>
good idea to<br>
introduce C to the codebase, but totally doable to have an<br>
SPI for<br>
policies.<br>
<br>
On 2016-04-25, Roelof Naude wrote:<br>
> hi,<br>
><br>
> a client has requested the use of the argon2 [1, 2]<br>
password hashing<br>
> scheme. this can easily be added as an external provider.<br>
we do however<br>
> require custom password policies, e.g. memory /<br>
parallelism cost as well as<br>
> salt length. AFAIK there is no way to provide policy<br>
extensions using a<br>
> provider interface?<br>
><br>
> would argon2 be a worthwhile contribution?<br>
><br>
> regards<br>
> roelof.<br>
><br>
> [1] <a href="https://github.com/P-H-C/phc-winner-argon2" rel="noreferrer" target="_blank">https://github.com/P-H-C/phc-winner-argon2</a><br>
> [2] <a href="https://github.com/phxql/argon2-jvm" rel="noreferrer" target="_blank">https://github.com/phxql/argon2-jvm</a><br>
<br>
> _______________________________________________<br>
> keycloak-dev mailing list<br>
> <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br></div></div>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>><span class=""><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
<br>
<br>
--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br></span>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
<br>
<br>
<br>
</blockquote>
</blockquote></div><br></div>