[keycloak-dev] Implementations for KEYCLOAK-2209
Stian Thorgersen
sthorger at redhat.com
Mon Sep 25 07:40:01 EDT 2017
On 18 September 2017 at 17:57, Ricardo Martin Camarero <rmartinc at redhat.com>
wrote:
> Hi Stian,
>
> I'm answering inline...
>
>
> On 09/18/2017 03:58 PM, Stian Thorgersen wrote:
> > Reading your email I couldn't figure out how you assign a password
> > policy to a user.
>
> The password policy is just assigned using an attribute in the user
> (like firstname or lastname). The only difference is that in option 1 it
> is single-valued and in option 2 it is multi-valiued (to test the
> merge). You can really play with it if you clone my repos and start the
> the server, create another password policy, create a user and assign a
> password policy to it (in the details tab).
>
I'm afraid I don't have time to look into your PR at the moment.
Are you saying that what password policy to use is configured per-user
based on an attribute? If so I don't think that's a good approach.
>
> > I think it would be best if there's an ordered/prioritized list of
> > password policies. Each policy would have a set of conditions on
> > whether or not the policy should be applied to a specific user. Where
> > conditions should include member/not-member of a specific group,
> > has/doesn't have a specific role, a specific attribute key/value or if
> > a user belongs to a specific user fed provider. If none matches the
> > last in the list should be used. I find having more than one policy
> > apply to a specific user just confusing so it should be the first
> > policy that matches for a user that is used.
>
> That is much more complex of what I was thinking and what KEYCLOAK-2209
> describes. My idea is much more simple:
>
> * The realm has a default password policy (the current one).
> * The user may have assigned a specific password policy.
> * Any group may have assigned a specific password policy (this part is
> not done in the branches).
> * As a user can result with several password policies assigned (because
> of the groups):
> Option 1: The policy with the highest priority applies.
> Option 2: Policies are merged (or all of them applied as the
> enhancement says).
>
> As you see my implementation is much more modest than your idea. Your
> idea can be later achieved with something like dynamic groups (a group
> that is automatically assigned because of an attribute in the user,
> because those groups can also have a password policy).
>
I'm not really following. What I'm suggesting is that the password policy
itself selects what policy to use, not the other way around.
>
> >
> > Now with regards to implementation it would make sense to convert
> > password policies to use component storage rather than add additional
> > tables/attributes for password policies. The single string password
> > policy was introduced before we had component storage and it is our
> > plan to eventually convert password policies to use component storage.
> > Component storage is much more flexible and powerful than what we have
> > today for password policies. It allows the provider itself to expose
> > what configuration applies to it.
>
> No idea about what is the component storage but ok, if you want me to
> continue with my modest approach I'll take a look to that and I'll move
> the password policies to component storage.
>
> Thanks.
>
> >
> > On 12 September 2017 at 19:59, Ricardo Martin Camarero
> > <rmartinc at redhat.com <mailto:rmartinc at redhat.com>> wrote:
> >
> > Hi team,
> >
> > I'm forwarding this email to the list following Stian's
> > recommendation.
> >
> > I needed to learn more about keycloak (how to manage the maven
> > project,
> > how to add a modification, how to test it, and so on and so
> > forth), so I
> > decided to start looking the code and try to help when I have some
> > free
> > time. As I filed an internal RFE because one customer wanted a
> similar
> > solution than the one specified in KEYCLOAK-2209 I started to
> > implement
> > something. Now I have two possible ideas that are not completely
> > implemented (I haven't done any group use for example). Both ideas
> > have
> > similarities:
> >
> > * I have extended the database to include a
> > REALM_PASSWORD_POLICY_GROUP
> > table that contains more policies associated to the realm. I thought
> > about using an attribute but I decided to extend the database because
> > the current policy attribute is a long string (length 2550). This
> > way in
> > the realm (policies page) now you can configure more than one
> password
> > policy (default is the current one and you can add new policies
> > that are
> > saved in the new table with a name).
> >
> > * The user has a new attribute that contains the password policy, in
> > this case I have re-used an attribute (I'm not sure about this
> > idea, now
> > I think using a new column would be better but I needed a multiple
> > attribute for option 2).
> >
> > * In both solutions I needed to extend the PasswordPolicyProvider
> > interface to pass the config to the two validate methods:
> >
> > PolicyError validate(RealmModel realm, UserModel user, String
> > password, Object config);
> >
> > I think there is a bug in this part in current master branch,
> > because
> > regex policy is multiple, and you cannot assign two different regex
> > providers in the same policy (PasswordPolicy stores the
> > configuration in
> > a Map<String, Object>, so you cannot have two different
> configurations
> > for the same type, if you assign two regex providers they are
> > transformed into one as soon as you save the policy).
> >
> >
> > Now the two implementations:
> >
> > 1) The first idea let us configure to a user one password policy. My
> > branch is this one:
> >
> > https://github.com/rmartinc/keycloak/tree/password-policy-groups
> > <https://github.com/rmartinc/keycloak/tree/password-policy-groups>
> >
> > In this solution the user has a combo (only one policy can be
> > assigned
> > to a user) and only one policy is applied to that user. My idea was
> > extending the idea using groups and priorities. Password policies
> will
> > have a priority, and only one policy will apply to a user (from
> > all the
> > possible policies the one with the higher priority applies). For the
> > moment I only modified keycloak to have a different policy in the
> user
> > (no priorities or group policies).
> >
> > 2) The second idea follows the description in 2209. The branch is the
> > following:
> >
> >
> > https://github.com/rmartinc/keycloak/tree/password-policy-
> groups-multi
> > <https://github.com/rmartinc/keycloak/tree/password-policy-
> groups-multi>
> >
> > Here the user can have multiple password policies. The definitive
> > policy is a merge between all the policies applied to the user. To do
> > this I needed to extend the PasswordPolicyProvider interface even
> > more,
> > in order to have a compare method that returns which policy is more
> > restrictive. Extending this idea to groups is just merging more
> > policies.
> >
> >
> > You can test my ideas (I think both of them are working). If you are
> > interested please let me know which idea you think is better (I'm not
> > completely sure, now I think that I prefer option 1, although option
> 2
> > is more similar to the RFE description, I think the latter is very
> > confusing). If you like one of them, I'll try to finish the
> > implementation (now there are no tests and some decisions I took
> maybe
> > are wrong). If you think this is not needed or it's not the time to
> > implement this RFE don't worry, it's ok, I needed to play with
> > keycloak,
> > and that part is done.
> >
> > Regards!
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >
> >
>
> --
>
> Ricardo Martin Camarero
>
> Software Maintenance Engineer
>
> Red Hat
>
> <https://www.redhat.com>
>
> <https://red.ht/sig>
>
>
More information about the keycloak-dev
mailing list