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

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

> > 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(a)redhat.com <mailto:rmartinc@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(a)lists.jboss.org <mailto:keycloak-dev@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>