Am 23.01.2013 10:59, schrieb Pierre Gaufillet:
>> > - How to set up a password for users? It seems impossible through the tree editor. > > Does it need to be done using the API?
>> There's User.setPassword(UserPassword), which is the setter of a *containment reference* . It should be available in the
> UI, too.
>
> In fact, I still don't see a mean to change password in the UI
> right-clic on a user/new child give only a grayed "Password" item and Annotation.
Ah, I remember now: I didn't do anything yet concerning the password management. I expected that these are set through
server API. It seems like a missing functionality, which is probably not too easy to design and implement such that it's
secure. Any thoughts on how this should appear to users/admins?

• User default rights: in SecurityManager, I see:
  

    protected CDOPermission getPermission(CDORevision revision, CDORevisionProvider revisionProvider,
        CDOBranchPoint securityContext, User user)
    {
      CDOPermission result = convertPermission(user.getDefaultAccess());
      if (result == CDOPermission.WRITE)
      {
        return result;
      }
  
      EList<Permission> allPermissions = user.getAllPermissions();
      for (Permission permission : allPermissions)
      {
        CDOPermission p = convertPermission(permission.getAccess());
        if (p.ordinal() <= result.ordinal())
  ...
  

  
  if I understand correctly this code, it means that if the default access right for a given user is WRITE, then it replaces any other right that may have been defined elsewhere for this guy. It is disturbing, as most of the time default rights apply, well... when there is no other applicable right. I would therefore rather move this code to the end of the method and would not only return WRITE, but also READ and NONE access rights.
  
• ClassPermission.isApplicable() should take care of inheritance. When you give write access to ENamedElement for exemple, you expect that EClassifier will inherit this right. Strict application may nevertheless be an option.
  
• ClassPermission: it would be nice to have nested StructuralFeaturePermission allowing to refine access right in a given Class, with a default feature right access defined in the ClassPermission.
  
• Security / Server life cycle: it seems that modifications in the security resource are only reloaded when the server is restarted. If it is really so, it is really annoying: an action should be provided to reload it on demand, or changes should be automatically reloaded after they have been committed.
  
• CDO editor: "Create child" actions should be grayed (or optionally removed) when the user has no right to create them. Currently, it is possible to create objects in a resource even if you do not have the write access, but the modification are rejected in block at commit time: it is quite frustrating.
  

Am 25.01.2013 15:57, schrieb Pierre Gaufillet:
>> > In fact, I still don't see a mean to change password in the UI
>> > right-clic on a user/new child give only a grayed "Password" item and Annotation.
>> Ah, I remember now: I didn't do anything yet concerning the password management. I expected that these are set
>> through server API. It seems like a missing functionality, which is probably not too easy to design and implement
>> such that it's secure. Any thoughts on how this should appear to users/admins?
>
>
> Well, Users may do this through an item in the menu of the CDO Sessions view, once logged in.
Good idea. Can you please submit an enhancement request?

> Administrators would need to do it through the Realm editor, on the User object.
It strikes me that Administrators should neither read user passwords nor set specific ones (that they would know then).
What about an action to just reset them to some newly generated one that is expected to be changed by the user later on?

> This one should probably completely mask the default Password creation item.
What do you mean by "mask"?

> Quote:
>> > Administrators would need to do it through the Realm editor, on the User object. It strikes me that Administrators should neither read user passwords
>> nor set specific ones (that they would know then). What about an action to just reset them to some newly generated
>> one that is expected to be changed by the user later on?
>
>
> And how do you transmit this new password to the user?
That's a major challenge which I have no answer for at this point ;-(

> I think Administrators are to be trusted:
I have to totally disagree with this assertion. I wouldn't want an administrator to have access to my secure bank
account or credit card information. Or a hacker who compromised the admin password to have access to *all* user
passwords. I doubt that a linux root user can read user passwords and that should be a hint.

• Either propose sending a reinitialized password to the email address (or cellphone number) of the user (if known). The account is locked as long as this password has not been changed by the user. Inconvenient: you need to connect the CDO server to a SMTP server (or SMS service), and to have a known email address (or phone number).
  
• Or propose answering to some secret questions that have been previously defined by the user. If the answers are corrects, prompt for a new password. If not, rely on the method above.
  

Am 29.01.2013 12:21, schrieb Pierre Gaufillet:
> Eike Stepper wrote on Tue, 29 January 2013 00:59
>> > Quote:
>> >> > Administrators would need to do it through the Realm editor, on the User object. It strikes me that
>> Administrators should neither read user passwords >> nor set specific ones (that they would know then). What about an
>> action to just reset them to some newly generated >> one that is expected to be changed by the user later on?
>> >
>> >
>> > And how do you transmit this new password to the user?
>> That's a major challenge which I have no answer for at this point ;-(
>>
>> > I think Administrators are to be trusted: I have to totally disagree with this assertion. I wouldn't want an
>> administrator to have access to my secure bank account or credit card information. Or a hacker who compromised the
>> admin password to have access to *all* user passwords. I doubt that a linux root user can read user passwords and
>> that should be a hint.
>
> I am not talking about read access, but write access. Administrators may only be able to impose a new password, not
> read it. This is something any Unix admin can do (admin who by the way can take the identity of any user in the system
> without knowing their password ).
That's an interesting point! It makes me aware that I have to rephrase my original assertion: If a password is set by a
user then noone else must be able to gain knowledge of it. The reason is obvious, that user might use it with other systems.

This opens the door for the following approach: Noone can read passwords (probably best to just store a hash of it). A
user can change it at any time, perhaps by repeating the old password again. An admin can change the password of any
user without repeating the old password of that user. It's the admin's responsibility to inform the user about the new
password and remind him to change it again as quickly as possible.

That may be what you had in mind

> Note that all this discussion also applies to the creation of CDO user accounts
Well, they're currently created by an admin or through server-side application code. So yes, the admin would also know
it for a while and would have to inform the user.

> and privilege settings.
How's that related?