Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

User Story #3527 (closed)

Opened 9 years ago

Closed 7 years ago

Call context support ("omero.group", "omero.user", etc.)

Reported by: jamoore Owned by:
Priority: critical Milestone: OMERO-4.4
Component: Security Keywords: n.a.
Cc: omero-team@… Story Points: n.a.
Sprint: n.a. Importance: n.a.
Total Remaining Time: 0.0d Estimated Remaining Time: n.a.

Description (last modified by jmoore)

Motivation

An initial phase of the public data work (#1733) is to once again allow querying over multiple groups, without requiring a user to create multiple sessions. This was disabled as we moved to group-based permissions (#1434 et al) in order to prevent clients from attempting to cross-link data between groups. This restriction, however, is too extreme, causing various forms of workarounds.

Sample usage

The call context of each remote method invocation is the passed via the code-generated last argument of all Ice methods. For a method defined as:

   interface IQuery {
      IObject get(string type, long id);
   };

in slice, Ice will generate both methods:

      IQueryPrx.get(String, long);
      IQueryPrx.get(String, long, Map<String, String>);

for OmeroJava, or in OmeroPy and OmeroCpp an optional argument:

      IQueryPrx.get(type, id, context=None)

For each of the types of context outlined below, an entry can be added to this map in order to effect the processing:

   Map<String, String> callContext = new HashMap<String, String>();
   callContext.put("omero.group", "-1");
   queryPrx.get("Image", 1L, callContext);

"omero.group"

The group context is usable by any user to change, thread-safely, the group that they are logged in to for the duration of one method call. Admins can use any group id value to log in to that group:

   callContext.put("omero.group", someUsersGroup);

or "-1" in order to log in to all groups:

   callContext.put("omero.group", "-1");

Regular users (non-admins) can set the value to any group that they are a member of or "-1", meaning "all of my groups".

"omero.share"

Similar to "omero.group", any member of a share can choose the id of the share which should be made active for the current method call. "-1" is supported for admins, meaning all data, but not for non-admins due to the complexity of determining what is contained in the given share.

Both "omero.group" and "omero.share" work identically to calling ServiceFactoryPrx.setSecurityContext with the given id value, except for the fact that the value does not persist beyond the single method call.

"omero.user"

Somewhat differently, the user context is usable only by admins in order to perform a sudo-like operation. If an admin would like to create an object for another user, or see what a query would return for such a user, then "omero.user" can be passed with a non-negative id. ("-1" has no meaning in this context). One stipulation is that the "omero.group" setting should also be set to match a group that the user is a member of, otherwise the user will receive a SecurityViolation for trying to access an improper group.

History

Initial work for this type of functionality took place in #2199. The chosen solution at that time was to use the "omero.group" setting as above, but internally to set the share id of the session to "-1" meaning make all data readable. This was only usable by admins.

Change History (9)

comment:1 Changed 9 years ago by cxallan

  • Milestone changed from OMERO-Beta4.3 to Unscheduled

comment:2 Changed 8 years ago by agilo

  • Status changed from new to accepted

Updated status, related task in progress

comment:3 Changed 8 years ago by jmoore

  • Milestone changed from Unscheduled to OMERO-Beta4.4

comment:4 Changed 8 years ago by jmoore

  • Cc omero-team@… added
  • Component changed from General to Security
  • Description modified (diff)
  • Summary changed from Initial public data work to Call context support ("omero.group", "omero.user", etc.)

comment:5 Changed 8 years ago by jmoore <josh@…>

(In [c26706f3f19aaf77f081875d1b8adf18ea3123bf/ome.git] on branch develop) Use LocalAdmin? in CurrentDetails? to refresh perms, etc (See #3527)

When an omero.group value is passed, it is necessary to not just set
the group id, but also the name and permission which have traditionally
been stored in the session context.

Here, we force a loading of the group and store its name and permissions
along with the id. The same happens for omero.user values.

comment:6 Changed 8 years ago by jmoore <josh@…>

(In [7aa7352db255aa386f515a1bd11745514fd22738/ome.git] on branch develop) Secure and test "omero.share" usage (See #3527)

Use of "omero.share":"-1" is not allowed except
for admins. For non-admins, the share must exist
and be accessible otherwise a SecurityViolation?
will be thrown.

comment:7 Changed 8 years ago by jmoore <josh@…>

(In [ec4b239e4caa71137253b039dc77b9b97c9b61ed/ome.git] on branch develop) Disable some omero.group API options (See #3527)

comment:8 Changed 8 years ago by jmoore <josh@…>

(In [8bb17d278460c34d5d7f2c1f2d300283e171655b/ome.git] on branch develop) Run import in group of target (See #3527, Fix #7814)

comment:9 Changed 7 years ago by jmoore

  • Resolution set to fixed
  • Status changed from accepted to closed

Only remaining ticket (#8190) has been pushed to 4.4.1. Closing.

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.307591 sec.)

We're Hiring!