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 > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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&gt; 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&gt; 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 >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >

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 > > > >

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

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 > > > > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev