nevermind. forgot to add the PasswordPolicySpi to the services file...

On Fri, Apr 29, 2016 at 2:48 PM, Roelof Naude <roelof.naude@gmail.com> wrote:
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@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@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@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@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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev