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