Open Microscopy Environment

Hi,

I'm currently working on a central user management for several platforms.
When looking for the user concerning tables of omero I was wondering where the information is stored (which table/s + entries) that a user is active or not.

Thanks for your help

Best regards

Fritz Lekschas

Hi Fritz,

by central user management, do you mean that you are trying to share users between different OMERO installations? Or more like LDAP integration?

In any event, the tables which define user management in OMERO are:

• experimenter
• groupexperimentermap
• experimentergroup

Each groupexperimentermap represents a users member in a group. There are two special groups, or roles: "user" and "system". Membership in "system" makes a user an administrator, and allows access to privileged API methods (The ones marked with @RolesAllowed("system")). Membership in "user" marks an active user with access to the rest of the API methods. Taking a user out of the "user" group, then, will deactivate them.

An alternative method for deactivating a user is by setting the password to null. This value is stored in the "hash" field of the "password" table, where "experimenter_id" is a foreign key for "id" of the "experimenter" table. (Note: an empty password hash permits passwordless login)

Hope that helps!
~Josh.

Thanks for the information.

Central user management is a website which should lets you easily organize the users for all the separate applications/platforms.
LDAP was our first choice but unfortunately half of the platforms/applications we are working with do not support LDAP.

Best regards,
Fritz

Okay So when I want to add or edit an user externally I have to care about the following tables:

1. experimenter (all the nessecary user information)
2. groupexperimentermap (user-group relations)
3. event (handles all events and gives them unique id's which are user as create_id and update_id in the groupexperimentermap)

Is there anything else I've forgotten?

Best regards,
Fritz Lekschas

Hi Fritz,

yes, sorry, I forgot the relationship to the event table in 4.1. In 4.2, this will go away. You can safely use Event(id=0) for creating the groupexperimentermaps if you'd like. Otherwise, if you include the "password" table, then your list looks good.

Are you making these changes at the SQL level or in code? If in code, what language? If Java, C++, or Python, then it would be possible to use the API directly to isolate yourself from future changes.

~Josh.

At the moment this "central user management" is just a small website. So I implement it with PHP and SQL.
Perhaps we'll switch to something better in the future but I don't know yet.

Thanks for your help

Best regards
Fritz