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:keycloak-dev@lists.jboss.org>>>> <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
> 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