Navigation:
Documentation
Archive



Page Tree:

Child pages
  • Managing groups across applications and platforms

This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.

Skip to end of metadata
Go to start of metadata

Overview

The Group Service deployed on the Bamboo Services Platform permits authenticated Bamboo Persons to create and populate groups, delegate administrative privileges, and organize groups in hierarchies.

These groups can be:

  • associated with resources served by the Bamboo Services Platform to permit access by members of the associated group(s); or,
  • used as factors in policies registered on the Bamboo Services Platform that come into play when rendering PERMIT or DENY decisions in response to a set of "what if" requests submitted by a client application / tool / service to the Request Manager Service.

One or multiple client applications / tools / services may therefore rely on Bamboo's centrally-hosted group and policy function to 'outsource' AuthZ decisions. This capability is especially useful where multiple clients wish to enforce the same policy on the same groups of users, e.g., to share access to resources across multiple research environments and their disjoint user communities.

In such cases, a client may wish to synchronize all or some of its locally-managed groups with groups defined by a 'master' membership roster maintained centrally and defined / managed by the Bamboo Group Service.

This document suggests – from a client application perspective – the process by which Bamboo group instantiation and management might occur, and how a client might take advantage of the centrally defined / managed groups.

It is noteworthy that:

  1. While the Bamboo Group Service is fully functional and has been tested with simple web service client tools (e.g., Poster, curl), integration of a client that manages its own local groups and that offers an end-user-appropriate interface was not accomplished during the first phase of the Bamboo Technology Project; the suggestions here are only that, and are not backed by a PoC implementation.
  2. While provision of a browser-based user interface for creating and managing Bamboo Groups was on the Bamboo Technology Project roadmap, the project's conclusion prior to a planned second phase of software development precluded this implementation. A goal of this unrealized implementation was to provide group management functionality in a centrally-run web application so that diverse Bamboo Ecosystem clients would not be required to build their own group management interfaces.

Simple group synchronization: thoughts on design and workflow

The following describe a thought-experiment in design and workflow for simply managing group synchronization between a client application (Research Environment, or RE) and the groups managed and accessed via the Bamboo Group Service.

These suggestions assume that the client RE is calling the Bamboo Group Service 'under the hood' via the Group Service API – without necessarily exposing these steps / mechanisms to the end-user.

Local-to-Bamboo group mapping

A local group can be associated with at most one Bamboo group.  The mapping between a local group and a Bamboo group is stored in the client RE's database and not elsewhere in the Bamboo Ecosystem (notably, not by any store accessible via the Bamboo Group Service). All synchronization operations are initiated and performed within the local RE. Bamboo group information is obtained from the Bamboo Group Service.

Create Bamboo group and associate a local group with it

Preconditions: The local user has authenticated and his/her BambooPersonID (BPId) is available in the current session.  The local user has group administration privileges for the local group in question.

A form in the client RE displays a list of local groups over which the current user has administrative privileges. The user selects one local group from the list and executes a "create new Bamboo group to associate with this group" action. All local group members for whom a BambooPersonID is stored locally are added to the Bamboo group, and local group administrators are given administration privileges for the Bamboo group.

Associate a local group with an existing Bamboo group

Preconditions: The local user has authenticated and his/her BambooPersonID is available in the current session.  The local user has group administration privileges for both the local group and for the Bamboo group with which the local group is to be associated.

A form running in the client RE displays a list of local groups and a list of Bamboo groups that satisfy the preconditions for the current user (i.e., groups for which the current user has administrative privileges). The user selects one item from each list to associate one group with the other. Saving the mapping causes the the groups to be synchronized. The user can choose to add all local members to the Bamboo group before a full synchronization is performed.

Full group synchronization

Full group synchronization treats the Bamboo group as the authoritative source for determining local group membership. All Bamboo group members who have local RE accounts will be added to the local group in the synchronization operation. All local group members who are not members of the Bamboo group will be removed from the local group in the synchronization operation.

Full group synchronization is performed periodically as determined by the local RE administrator. We will likely want to experiment with synchronization scenarios based on the user experience. It could be that we assign a "stale" period to a group, such that when a user logs into the RE and more time has passed since a group was last synchronized than the assigned stale period, then the full synchronization is run for the group.

Note that full group synchronization implies that BambooPersonIDs for local users are persisted locally or that they can be discovered.

Partial synchronization

When a local user authenticates and her BambooPersonID is established for her current local session, all local groups for which there is a Bamboo group mapping will be synchronized for this user and only this user. This operation provides for the possibility that the user has been added or removed from a Bamboo group through an action performed elsewhere in the Bamboo Ecosystem in the time since the last full group synchronization operation was performed.

Synchronization for a single user means that this user's local group memberships, for all local groups for which there is a Bamboo group mapping, are updated so that they are consistent with her/his memberships in the mapped, master Bamboo groups.

Adding/removing local group members

Consider the following two approaches:

Approach A - adding/removing local group members

Preconditions: The local user has authenticated and his/her BambooPersonID is available in the current session. The local user has group administration privileges for both the local group and for the Bamboo group.

When a local group administrator adds a local user to a group or removes one from a group, that action is replicated in the Bamboo group to synchronize the local group and Bamboo group memberships. It may be that this replication needs to be triggered through a separate action performed by the user.

Approach B - adding/removing local group members

Preconditions: The local user has authenticated and his/her BambooPersonID is available in the current session. The local user has group administration privileges for both the local group and for the Bamboo group.

An interface is provided within the client RE for adding and removing members from a Bamboo group. After performing group membership maintenance at this level the group administrator triggers a full synchronization with the local group.

Partial synchronizations provide for the possibility that group memberships may have been altered from an interface in another RE.

If this interface also provides for assigning group administration privileges, or if group administration could be set from a centrally-deployed group management application accessible to Bamboo Persons (as described in the Overview section above), a mechanism for effecting group associations across client applications / REs would be realized.

Dissociating a local group from a Bamboo group

Preconditions: The local user has authenticated and his/her BambooPersonID is available in the current session.  The local user has group administration privileges for both the local group, but need not have administration privileges for the Bamboo group.

On the local-to-Bamboo groups mapping page, a local group administrator can select a group for which she has administration privileges and that is associated with a Bamboo group, and elect to break the association. This action has no consequences for local group membership; it merely removes the local group from the set of groups that are fully or partially synchronized with the Bamboo groups.

Unresolved or out-of-scope issues 

  • How administration privileges are granted for local or Bamboo groups. The attentive reader will have noticed that in order to establish the synchronization relationships between local and Bamboo groups across several REs, either the same BambooPerson is an administrator in all of these local groups and in the Bamboo group OR the Bamboo group has more than one administrator and the administrators are appropriately distributed to the REs, i.e. at least one Bamboo group administrator is present in each RE. While the Bamboo Group Service API provides a mechanism to support the second case, a group management web application independent of any single client RE may be necessary in order to effect delegation of administrative privileges across populations of Bamboo People who do not have local accounts in a single client RE (e.g., the client RE from which the Bamboo group is created). This seems to be a likely use case: we want to create a Bamboo group so that two disjoint workgroups situated in different REs can share data. Building and deploying an independent group management interface accessible via a web browser is therefore a likely necessity.
  • How local groups are created and maintained in a client application / tool / service (RE) is left as an exercise to client developers.
  • Notice that group membership rosters will occasionally fall out of sync between the central group store and local RE stores. That is, we have not yet imagined a mechanism to push changes out to REs when a change is made in the central Bamboo store. This assumes that some latency in synchronization is acceptable.

 

  • No labels