10:11 p.m.
Admin user can reset the password of any user without knowing the old
password though? It's also possible to reset password directly with
model API. So I wonder if we can have configuration option, which will
allow to specify what to do when federation provider is removed. The
options might be:
* Delete all linked users
* Reset password of linked users and add required action for change
passwords
Maybe the most flexible solution is to add method like "onRemove" to
UserFederationProvider interface? This will allow implementors to define
what exactly to do with linked users (For LDAP I can imagine either
delete or reset password according to boolean config option mentioned above)
Marek
On 1.8.2014 15:34, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Friday, 1 August, 2014 2:23:39 PM
> Subject: Re: [keycloak-dev] delete users on federation removal?
>
>
>
> On 8/1/2014 4:18 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke(a)redhat.com>
>>> To: keycloak-dev(a)lists.jboss.org
>>> Sent: Thursday, 31 July, 2014 11:01:12 PM
>>> Subject: Re: [keycloak-dev] delete users on federation removal?
>>>
>>> Ya, this is quite hairy. You'll have to set the REQUIRED ACTION to
>>> reset all credentials handled by the federation provider.
>>>
>>> Unfortunately, you can now only set one required action per user :(
>> You can still set multiple. The user has a Set<RequiredAction> and we even
>> have a test that checks users with multiple actions
>> RequiredActionMultipleActionsTest.
>>
> Ugh, I'm really sorry. I think I remembered you saying you were going
> to switch it to one action, looked at the code quickly and missed the
> Set<RequiredAction> method on UserModel...I AM LOSING MY MIND!!!!
Honest mistake, I switched the authorization code so it's only valid for one action
at a time. So if a user has multiple required actions, the code will be set to the first
one, then the user redirect to that action page, then the code will be updated with the
new action + timestamp refreshed, redirected to next action page, etc.. Keeping the spirit
of code is a one-time-thing alive ;)
> Still not sure what to do about credentials though. We can't have open
> accounts that can be reset without specifying old password. We could
> send out an email maybe.
>
> Must be deferred to post 1.0.final.
+1 To deferre it
One related thing I think we'll need is the ability to do batch updates to users. For
example an admin may want to:
* Require a group of users to update their password
* Disable a group of users
* Add a role to a group of users
Not sure how the admin would specify the group though, maybe by role?
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev