When a user is edited, if the user who is doing the editing does not have at least read-access to the roles assigned to the user being edited, these roles will be deleted when the user is saved.

Not only that, but they will be "partially" deleted, resulting in an incorrectly configured user node which can still work, but causes exceptions in the login-processing. (See stack trace in comments).
This is because when the roles are deleted, the property for the deleted role is not removed, but only its content is deleted, leaving an empty property attached to the "roles" node in the user node.
This results in an NPE when the security attempts to instantiate the UUID.

Suggested fix:
Don't delete roles the current user cannot read when the user dialog is saved!

Undesireable, but better than the status-quo:
Delete the roles properly.

Background info:

We are implmenting a kind of delegated security model for our customer:

• Roles and Groups are configured exclusively by us (we have superuser rights)
• Admins on the customer side have the right to create and manage users
• They can assign groups to the users
• They can read (but not write!) the groups
• They cannot read or write the roles

In this way, we set up the security policies via the roles we create for the customer, and assign the roles to groups which the customer can use to configure which user can do what.
The customer has hundereds of users, which is why we do it this way.