Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] "A" and "B" lists for v0.9

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] "A" and "B" lists for v0.9

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Tom Barton <>,
  • Subject: Re: [grouper-dev] "A" and "B" lists for v0.9
  • Date: Tue, 11 Oct 2005 14:52:06 +0100

I've added comments to some of the B list items below.


--On 06 October 2005 18:25 -0400 Tom Barton

Following is a summary of the discussion of v0.9 tasks that took place on
the grouper-dev call last Wed.

We agreed that certain tasks are to be in scope for v0.9 without further
discussion. These are identified in the "A" list below. Other potential
work items need further discussion or clarification. These are gathered
in the "B" list below. B-list tasks also need to be prioritized and
slotted to a release, which might, but need not, be the 0.9 release.


Grouper v0.9 "A" list

Tasks included in the 0.9 scope of work.

A1. API & UI: performance profiling & optimization

A2. API: refactoring, richer exception set, transactional atomicity

A3. UI: adjust to and take advantage of A2, other UI refactoring

A4. API & UI: support special grouper-specific subjects. We still need to
finalize the precise specs:
. should the ALL (or ANY??) token signify all authenticated subjects
or anonymous users? Or should there be two such tokens, one for each?
. should GrouperSystem be a special subject and no longer a person
. should the "wheel" group, ie, those subjectIDs permitted to act with
the privilege of GrouperSystem, be just another group in the Group
Registry or should it be a special one?

A5. API & UI: namespace-scoped searching

A6. API & UI: discuss initial group math design (not for implemention in

A7. API & UI: a few bug fixes.


Grouper "B" list

Tasks for further discussion, clarification, and assignment to the 0.9
release or later releases (or consignment to /dev/null). The "B" list is
not meant to be exhaustive of all tasks remaining in scope for the
Grouper project, but likely does reflect those that are up sooner in the
work queue.

B1. API & UI: limited support for extended group types and fields

Level 1. Sites currently can manually edit the grouper_field,
grouper_typeDef, and grouper_type tables to define additional fields,
their security, and associate them with existing or new group types. The
API should expose the field and type structure and support assignment of
multiple types to a group. The UI should enable a group type or types to
be selected when creating a group, display fields in the group summary
page according to the type(s) bestowed on the group, and support editing
of fields according to the type(s) bestowed on the group (non-list fields
on the edit group page, and list field(s) in list management pages). In
addition to the API, the GrouperSourceAdapter should be extended to
expose all (non-list, for now) fields of each group, taking into account
the types bestowed upon it.

Level 2. API or UI support for managing the set of group fields or group
types - that will continue to be done by manual editing of the underlying
tables as stated above. Not for the 0.9 release.

B2. UI: improve membership management by better exposure of effective
membership and subject attributes

UI users are not currently shown information that reveals how a given
subject has attained effective membership in a group. Users should be
presented with that information, within the constraints of their access
privileges. A new "subject summary" page will list all of the specified
subject's immediate & effective memberships. How immediate memberships
should be presented in relation to the effective memberships that they
qualify remains to be discussed. Selecting a group in this presentation
cancels the session's current focus and establishes a new one at the
selected group. The subject summary page will also present whatever
attributes are available about that subject through the Subject API.

The subject summary page should be available from the top level menu and
by some kind of link associated with checkbox lists of subjects presented
in membership management pages.

Should group subjects also be presented this way, and using attributes
about them exposed through the Subject API? I guess this would replace
the current group summary page if so.

By default the UI shows 'immediate' members as links, which, if clicked, allow the user to remove membership, and / or, assign / revoke access privileges. Effective members are not links and there is no way to determine how the effective membership came about. Previously, effective members were linked as immediate members, however, this was unsatisfactory because it gave the impression that an effective membership could be removed directly, whereas this can only be achieved indirectly e.g. consider that Subject A is a member of Group A which is a member of Group B which is a member of Group C which is a member of Group D i.e.

Subject A -> Group A -> Group B -> Group C -> Group D

Currently, in order to 'remove' the effective membership of Subject A from Group D you would have to do ONE of the following:
1) Revoke Subject A's membership of Group A, or
2) Revoke Group A's membership of Group B, or
3) Revoke Group B's membership of Group C, or
4) Revoke Group C's membership of Group D

In the future group math may give other options.

The situation may be more complicated e.g. if Group B was also an immediate member of Group D, 1 and 2 would work, but 3 and 4 would only work if Group B's immediate membership of Group D was also revoked.

If a Subject is a member of a group via multiple routes, the UI currently lists each membership separately, so a subject may appear several times. If such a subject appears in the list at a 'page break' it is not immediately apparent whether there are further 'instances' of the subject on the next page. In addition, the 'count' of memberships will often not reflect the count of unique subjects which are members of a group.

From a UI perspective, it would make sense to show a subject once, perhaps with an indication of whether membership is immediate, effective or both. In this case clicking on a link would, if there are multiple routes, display a summary of the routes with the option of linking to screens where relevant membership changes may be made. Of course, these screens must take account of the relevant access privileges. On occasions it may be necessary to indicate that an effective membership exists but not show how it was derived, or to not offer a link to change such a membership.

The GrouperGroup.list(XXX)Vals methods would either need to be changed / supplemented to give 'unique' lists, preferably of an object which indicates the subject and a list of memberships, or the UI could process the list to give such a structure.

Currently, given a GrouperMember, it is possible to list all memberships for that member. It would be convenient to have an option to specify a group so that only memberships of that group are returned. The UI could achieve this by filtering the list, but it might be more efficient for the API to only select the relevant memberships.

Subject summary page
I see a 2 stage Subject Summary page:

1) Display of attributes + 'visible' groups the subject is a member of - with an indication of whether immediate / effective / both; if READ privilege for groups or STEM privilege for a stem, list groups / stems the subject has Access / Naming privileges for

2) Clicking a group link from 1) would lead to a screen which would, if an immediate membership only, allow revocation of membership. If one or more effective memberships were present it would lead to a screen as described for membership management i.e. one which shows the routes to membership

A new menu item e.g. Subject search, would allow a user to use a subject centered approach, with search results linking to the summary page. In addition, other places in the UI where subjects are listed would have an additional link to the subject summary page.

B3. UI: subject search improvements

Level 1. In the simple search, remove current per-subjectType restriction
on searching and just search across all configured sources regardless of
type. Type (and source) of search hits are returned in addition to
subject name and description. Search hits are displayed with associated
links that point to subjects' summary pages.

Level 2. Initial form of advanced search to be implemented. This will
include selection of subjectType(s), source(s), namespace scope for group
searches, and limiting search terms to selected subject attributes,
provided the Subject API exposes such a capability. Attribute search
restriction functionality should be discussed with the Signet team in
connection with the Subject API.

level 1: I'm not sure about doing searches across all sources - or I might be happier if this was done through the Subject API itself.

B4. Better management of "effective" privileges

Grouper's default access & naming privilege implementations rely on group
management capabilities, enabling a privilege to be effectively bestowed
on a subject by virtue of that subject belonging to a subgroup of a group
directly granted the priv. However, the access & naming interfaces
presume a flat model of privilege - a subject either has it or not. This
has led in 0.6 to a somewhat misleading presentation of privilegees and
an inability to actually revoke privilege in some circumstances (in which
the user has authority to revoke).

A related constraint is that access & naming interfaces must not expose
or presume grouper-specific implementation details, in order to preserve
the ability for external privilege management systems to be integrated
with Grouper.

I believe Gary's on the hook to send to the list a proposed approach to
The current Access and Naming APIs are effective at checking whether a subject has a privilege, or listing privileges a subject has, or listing all subjects with a given privilege for a group or stem, however, they cannot be used to manage privileges effectively.

In the UI, when listing Subjects with a specific privilege, it would be useful to indicate whether the privilege was assigned directly to the Subject or if it was derived from the subject's membership of a group.

When selecting a subject to manage their privileges for the current group or stem, we must be able to differentiate 'immediate' privileges - which can be managed here, from 'effective' privileges which should be managed in the context of the Group to which immediate privileges were assigned.

How does this fit in with external privilege management?

We should expect any privilege management system integrated with Grouper to 'know' which privileges have been granted directly to which subjects, and so, by default, we could show the 'immediate' list of privilegees. In the Grouper UI, where a subject is also a GrouperGroup, we can provide links for listing the membership of those groups, or we could list all privilegees as we do now.

The Access and Naming APIs have equivalent methods so I'll only discuss The Access API here:

List has(GrouperSession s, Group g, GrouperMember m)

returns a list of privs. It should either return a list of objects which indicate the privilege and the Group (if any) which has the 'immediate' assignment, or a new method which does so should be added to the API.

List whoHas(GrouperSession s, Group g, String priv)

returns a list of GrouperMembers with the privilege. If it returned GrouperList objects the UI could determine whether the privilege was immediate or effective. Similar to group membership, it may make sense to return one object per Subject and give that object a means of listing all the ways a privilege has been granted.

Clearly Grouper can fullfill these requirements, but what about external privilege management systems? In the best case scenario the system will be 'group aware' i.e. knows that groups have members, can list those members and can determine, in the example:
Subject A -> Group A -> Group B -> Group C -> Group D
that if Group D has READ privilege for X, so does Subject A, and can more specifically answer 'true' to the query:
does Subject A have READ privilege for X

in this case it would be straightforward to write a GrouperAccess implementation.

In the worst case scenario where a privilege management system is not 'group aware' and can simply answer if a subject has an 'immediate' privilege for a group, or can list only direct privilege assignments, then the GrouperAccess implementation class has to do more work i.e. in the case:

List has(GrouperSession s, Group g, GrouperMember m)

Implementation is:

privs = PrivManagementSystem.listAllPrivilegesForGroups
foreach (priv in privs) {
list = PrivManagementSystem.listAllWithPrivilegeForGroup(,priv)
foreach (privilegee in list) {
if(privilegee == m) add 'priv' to result list
else if(privilegee is group and m is a member of group) add 'priv' to
result list - and record group
//else not of interest

In the case:
List whoHas(GrouperSession s, Group g, String priv)

Implementation is:

list = PrivManagementSystem.listAllWithPrivilegeForGroup(,priv)
foreach (privilegee in list) {
add 'privilegee' to result list
if(privilegee is group) add 'group members' to result list - and record

Therefore, any privilege management system ought to be able to manage Grouper privileges.

NB. Internally Grouper uses GrouperList objects and these map to entries in the grouper_list database table. When dealing with privileges another object may be necessary since there won't be any grouper_list rows equivalent to privileges.

B5. Determination of an XML document model for use as an integration
artifact. Certainly an export artifact to drive provisioning processes,
possibly as an import artifact to load groups & namespaces and assign
naming & access privs.

RL Bob is on the hook to make an initial proposal along these lines.
I use grouperqs/quickstart.xml as an import artifact.


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page