search

GluuFederation / oxTrust

Gluu Server UI for managing authentication, authorization and users.
https://gluu.org/docs/ce
MIT License
134 stars 60 forks source link

[CR] Implement a new CR logic that would allow it to initiate full update of user objects in its internal db when changes to mappings are detected #164

Closed aliaksander-samuseu closed 7 years ago

aliaksander-samuseu commented 8 years ago

This is from the selection of enhancements that @nynymike and @yurem came up with when discussing current CR's drawbacks. Please also see another card related to this one: CR needs to become able to remove attributes of internal user objects managed by it for which no mappings exist anymore

At the moment CR is unable to detect the need to update internal user objects when the list of attributes to pull isn't changed, but mappings are.

If mappings were changed between CR's iterations, it must save the mapping scheme used at its last pulling iteration before updating it with new one provided by a user, and at the next iteration compare previous an current schemes together to detect whether or not it should update all user objects in internal db due to changes in how attributes from a backend are distirbuted in it. Yura objected that we shouldn't deny a user ability to trigger full update by simply reordering mapping tupples (i.e. without actually changing how attributes are distributed), but I think if we will chose to implement the button to manually trigger full update (which I think is a useful feature anyway), it would be more effective to not set the parameter in such cases. This process shouldn't change inum of the internal user object (as I suppose it may be used to ensure some kind of id persistence)

As for how to implement it, Yura proposed to add a new parameter for CR which can be used to force full CR update of all user objects in internal LDAP db. It can be set to true if there are changes in mapping detected using algorithm mentioned above. Additionally, a button could be added which also sets this parameter, so user could manually trigger the update if it didn't happen automatically for whatever reason.

aliaksander-samuseu commented 8 years ago

On a second thought, it seems to me just adding a button that will force update is more preferable way.

  1. It's much more simple solution, thus less bugs/missfires/etc
  2. Even if implemented in automated manner, the button should probably be added anyway, to allow user to intervene if script isn't working correctly.

Then it can be covered in docs and a hint to click the button that will be displayed each time user changes mappings can be added to the page. Implementing it this way will also make the answer to question of whether or not to start update when mappings were simply reordered unnecessary: the user will be able to gauge and decide for himself, or just click it every time, just in case, if he wishes.

willow9886 commented 8 years ago

should there just be a button to force a refresh of all user?

aliaksander-samuseu commented 8 years ago

@willow9886 yes, in the end, I think this would be most rational solution. We can think whether or not it worth further automation later. But at least we should provide user with a straightforward way to update all pulled in user entries when some mappings were changed. The main CR tab also should display a clearly visible hint warning user that he must click that button to really make his changes to apply each time he modifies some mappings.

aliaksander-samuseu commented 8 years ago

@willow9886 optionally, this new feature should be able to detect when such refreshment of all user entries is indeed needed, as not all changes to mappings will result in actual changes to how attributes' values are being distributed, to exclude unnecessary updates which can put a significant strain on the server in case of instances storing an enormous amount of user entries.