Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

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

Gary

--On 06 October 2005 18:25 -0400 Tom Barton 
<>
 wrote:

> 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
> subjectType?
>    . 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
> 0.9)
>
> 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
> B4.
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:

Currently,
        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.

Currently,
        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(g.id(),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(g.id(),priv)
foreach (privilegee in list) {
 add 'privilegee' to result list
 if(privilegee is group) add 'group members' to result list - and record
     group
}

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.
> Tom



----------------------
GW Brown, Information Systems and Computing